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Foreword 

This Technical Specification (TS) has been produced by ETSI Technical Conmiittee Access, Terminals, Transmission 
and Multiplexing (ATTM). 

The present document is part 6 of a multi-part deliverable covering Access, Terminals, Transmission and Multiplexing 
(ATTM); Integrated Broadband Cable and Television Networks; IPCablecom 1.5, as identified below: 
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'Architectural framework for the delivery of time critical services over cable Television networks using 
cable modems"; 

'Audio Codec Requirements for the Provision of Bi-Directional Audio Service over Cable Television 
Networks using Cable Modems"; 

'Network Call Signalling Protocol"; 

'Dynamic Quality of Service for the Provision of Real Time Services over Cable Television Networks 
using Cable Modems"; 
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'Media Terminal Adapter (MTA) Management Information Base (MIB)"; 

'Network Call SignalHng (NCS) MIB Requirements"; 

'Security"; 

Management Information Base (MIB) Framework"; 
'Media Terminal Adapter (MTA) device provisioning"; 
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Part 21: " Signalling Extension MIB Specification" . 

NOTE 1: Additional parts may be proposed and will be added to the list in future versions. 

NOTE 2: The choice of a multi-part format for this deliverable is to facilitate maintenance and future 
enhancements. 
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1 Scope 



The present document describes the concept of Event Messages used to collect usage for the purposes of billing within 
the IPCablecom 1.5 architecture. It details the RADIUS protocol used to carry these messages, defines the various 
Event Messages, lists the attributes each Event Message contains, and lists the required and optional Event Messages 
associated with each type of end-user service supported. 



References 



References are either specific (identified by date of publication and/or edition number or version number) or 
non-specific. For specific references, only the cited version applies. For non-specific references, the latest version of the 
reference document (including any amendments) applies. 

Referenced documents which are not found to be publicly available in the expected location might be found at 
http://docbox.etsi.org/Reference . 

NOTE: While any hyperlinks included in this clause were valid at the time of publication ETSI cannot guarantee 
their long term validity. 

2.1 Normative references 

The following referenced documents are necessary for the application of the present document. 

[I] Void. 

[2] PKT-SP-SEC1.5- 102-070412: "PacketCable 1.5 Security Specification", April 12, 2007, Cable 

Television Laboratories, Inc. 

[3] PKT-SP-DQOS 1.5-104-090624: "PacketCable 1.5 Dynamic Quality of Service", March 29, 2007, 

Cable Television Laboratories, Inc. 

[4] IETF RFC 2865 (2000): "Remote Authentication Dial In User Service (RADIUS)". 

[5] IETF RFC 2866 (2000): "RADIUS Accounting" . 

[6] Telcordia GR-1 100-CORE: "BAF Generic requirements". 

[7] ETSI TS 103 161-16: "Access, Terminals, Transmission and Multiplexing (ATTM) Integrated 

Broadband Cable and Television Networks; IPCablecom 1.5; Part 16: Signalling for Call 
Management Server" . 

[8] ETSI TS 101 909-20: "Digital Broadband Cable Access to the Public Telecommunications 

Network; IP Multimedia Time Critical Services; Part 20: Lawful Interception". 

[9] ITU-T Recommendation E.164 (2005): "The International Public Telecommunication Numbering 

Plan". 

[10] IETF RFC 1305 (1992): "Network Time Protocol (Version 3), Specification, Implementation and 

Analysis". 

[II] Void. 
[12] Void. 
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2.2 Informative references 

The following referenced documents are not necessary for the application of the present document but they assist the 
user with regard to a particular subject area. 

.1] Void. 

.2] PKT-TR-ARCHl .5-V02-070412, PacketCable 1 .5 Architecture Framework Technical Report, 

April 12, 2007, Cable Television Laboratories, Inc. 

.3] ETSI ES 201 488-2: "Access and Terminals (AT); Data Over Cable Systems; Part 2: Radio 

Frequency Interface Specification" . 

.4] PKT-TR-CF-ON-ON- V03-0308 1 5 : "PacketCable Architecture Call Flow Technical Report, On- 

Net MTA to On-Net MTA" August 15, 2003, Cable Television Laboratories, Inc. 

.5] PKT-TR-CF-ON-PSTN-V02-030815: "PacketCable Architecture Call Flow Technical Report, On- 

Net MTA to PSTN", August 15, 2003, Cable Television Laboratories, Inc. 

.6] PKT-TR-CF-PSTN-ON-V03-030815: "PacketCable Architecture Call Flow Technical Report, 

PSTN to On-Net MTA", August 15, 2003, Cable Television Laboratories, Inc. 

.7] GR-1298-CORE, AINGR: Switching Systems (GR-1298). 

.8] GR-1299-CORE, AINGR: Switch - Service Control Point (SCP)/Adjunct Interface (GR-1299). 

.9] GR-533-CORE, LSSGR: Database Services Service Switching Points - Toil-Free Service (FSD 

31-01-0000), A Module of LSSGR, FR-64 (GR-533), Telcordia. 

.10] GR-2892-CORE, Switching and Signaling Generic Requirements for Toil-Free Service Using AIN 

(GR-2892), Telcordia. 

.11] TRQ No. 2, Technical Requirements Number 2, Number Portability Switching Systems (ANSI 

T1S1.6 Working Group). 

.12] Internet Protocol Standards - STD9, October 1985, J. Postel, J. Reynolds, File Transfer Protocol 

(TFP). 

.13] ETSI TS 101 909-15: "IPCablecom Services for delivering multimedia and voice over DOCSIS 

network infrastructure". 

.14] Telcordia GR-605-CORE - LSSGR: Authorization Codes for Automatic Flexible Routing (AFR) 

and Account Codes for Basic Business Group and AFR (FSD 02-02-1010) - Telecordia. 

.15] Telcordia GR-580-CORE LSSGR: Call Forwarding Variable, Telecordia. 

.16] Telcordia GR-586-CORE LSSGR: Call Forwarding Subfeatures, Telecordia. 

.17] Telcordia GR-317-CORE LSSGR: Switching System Generic Requirements for Call Control 

Using Integrated Services Digital Network User Part (ISDNUP). 

. 1 8] GR-2936-CORE Local Number PortabiHty Capability Specification, Telecordia. 

.19] IETF RFC 2620: "RADIUS Accounting Client MIB". 
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3 Definitions and abbreviations 

3.1 Definitions 

For the purposes of the present document, the following terms and definitions apply: 

attribute: Event Message Attribute is a predefined data element described by an attribute definition and attribute type 

cable modem: layer two termination device that terminates the customer end of the DOCSIS connection 

cable modem termination system: as used in this standard, a CMTS is a layer two termination device that terminates 
the network end of the DOCSIS connection 

NOTE: It is technology specific. 

call: instance of user-initiated voice communication capabilities 

NOTE: In traditional telephony, a call is generally considered as the establishment of connectivity directly 

between two points: originating party and terminating party. In the IPCablecom context, as noted above, 
the communication between the parties is "connectionless" in the traditional sense. 

event message: set of data, representative of an event in the IPCablecom architecture that could be indicative of usage 
of one or more billable IPCablecom capabilities 

NOTE: An Event Message by itself may not be fully indicative of a customer's billable activities, but an Event 
Message correlated with other Event Messages builds the basis of a billable Usage Detail Record. 

IPCablecom transaction: collection of events on the IPCablecom network when delivering a service to a subscriber 

NOTE: Event Messages for the same transaction are identified by one unique Billing Correlation ID (as described 
in table 32). For some services, multiple transactions may be required to provide information that is 
necessary to collect the total usage for the service. Multiple Event Messages may be required to track 
resources for each individual service used. A transaction may persist over time. 

IPCablecom: project that includes an architecture and a series of standards that enable the delivery of real-time services 
over the cable television networks using cable modems 

service: individual or package of communications features a subscriber may select 

NOTE: A service is identified by a set of one or more "calls" or transactions that deliver the desired functionality 
to the subscriber. Examples of a service include: a voice communication between two local IPCablecom 
subscribers, a 3-way call, pay-per-view movie, and a web surfing session. A service may be instantaneous 
or persist over time. 

3.2 Abbreviations 

For the purposes of the present document, the following abbreviations apply: 

Ack Acknowledgement 

AMA Automated Message Accounting 

BAF Bellcore AMA Format 

BCID Billing Correlation ID 

BSS Business Support Systems 

CDR Call Detail Record 

CF Collection Function 

CM Cable Modem 

CMS Call Management Server 

CMSS Call Management Server Signalling 

CMTS Cable Modem Termination System 

DF Delivery Function 

DLCX DeLeteConnection 

DQoS Dynamic Quality-of- Service 
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DTMF Dual-tone Multi Frequency 

EM Event Messages 

FEID Financial Entity ID 

FID Flow Identifier 

lAM Initial Address message 

lANA Internet Assigned Numbers Authority 

IP Internet Protocol 

ISUP ISDN User Part 

LEA Law Enforcement Agency 

LIDB Line Information Database 

LNP Local Number Portability 

LRN Location Routing Number 

MGC Media Gateway Controller 

MTA Media Terminal Adapter 

NCS Network Call Signalling 

NE Network Element 

NTP Network Time Protocol 

OSS Operations Support System 

PSTN Public Switched Telephone Network 

QoS Quality of Service 

RKS Record-Keeping Server 

RLC Release Complete Message 

SDP Session Description Protocol 

SFID Service Flow ID (SFID) 

SS7 Signalling System No. 7 

TCAP Transaction Capabilities Application Protocol 

TGCP Trunking Gateway Control Protocol 

VoIP Voice over IP 

VSA Vendor Specific Attributes 



Void 



5 Technical Overview 

5.1 Traditional Telephony Billing Formats 

The telephony industry has traditionally recorded call detail transactions on telephone switches utilizing various 
standard and proprietary billing formats such as Automated Message Accounting (AM A), sometimes referred to as 
Bellcore AM A Format (B AF). The switches generate multiple transactions based upon the type of call the customer 
placed. These transactions are correlated and packaged into a single Call Detail Record (CDR) at the end of the service 
instance for billing purposes. In this traditional telephony model, services and awareness of "call state" is usually 
maintained in one or at most two nodes of the network, which makes such correlation relatively straightforward. The 
CDR is then delivered to the billing system for the purpose of placing a charge on the customer's account. 

5.2 Motivation for Event Based Billing 

The event-based approach to capturing information to be used for billing is necessary to accommodate the distributed 
architecture of IPCablecom. "Call state awareness" no longer resides in one or two network elements, but is instead 
spread out among many. Each network element shall be responsible for generating Event Messages for the portion of 
the communication pertaining to them. 

The primary motivating factor behind articulating the structure and details of these various Event Messages is to support 
multi- vendor interoperability between network elements and record keeping servers. The present document defines the 
Event Message syntax and in addition it describes the transport protocols. 
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Event based billing has the added advantage that it enables IPCablecom services to be billed in real-time, making the 
information about billable communications available as the network equipment processes them. This allows the system 
as a whole to be more responsive, allowing, for example, fraudulent behaviour to be detected sooner, saving revenue for 
the provider. It also allows a more fully integrated solution, as it becomes possible for the billing system and the 
network equipment to exchange information about the availability of a service as the customer is requesting that 
service. 

With respect to the Event Message format, there are a large number of formats in use today. The most widely used 
formats carry the legacy of the traditional CDR, which is generated at the end of the call. While these formats capture 
much of the information content needed to bill for IPCablecom services, bringing along their full structure would make 
it difficult to support the real-time nature of certain enhanced IPCablecom services. The present document leverages the 
value of the information content from the existing billing formats, augmenting that with the distributed nature of the 
IPCablecom architecture. 

5.3 Originating/Terminating Call Model to Support Customer 
Billing and Settlements 

The IPCablecom Event Messages contain sufficient per-call information to support customer billing for service as well 
as settlement between IPCablecom network providers for access. The information contained in the Event Messages 
supports a wide variety of billing and settlement models. IPCablecom does not mandate the use of specific billing or 
settlement models as these models are defined by and based on the specific business requirements of the individual 
cable operators. IPCablecom neither mandates nor precludes the use of a clearinghouse for settlements. 

The IPCablecom Event Messages are based on a model where a call or service is divided into an originating half and a 
terminating half. The originating CMS or MGC shall generate a unique Billing Correlation ID (BCID) to identify all 
Event Messages associated with the originating half of the call. The terminating CMS or MGC shall generate a unique 
BCID to identify all Event messages associated with the terminating half of the call. For each half of the call or service, 
the set of IPCablecom network elements that generate Event Messages (CMS, MGC, CMTS) must provide all 
necessary information required for billing and/or settlements as appropriate based on the service. The information 
generated by the originating half shall be sent to the RKS supporting the originating half. The information generated by 
the terminating half shall be sent to the RKS supporting the terminating half. The IPCablecom network elements also 
generate Event Messages that are not associated with any call. For those cases, the network element generating the 
Event Message shall generate a unique BCID for the event and send the Event Message to appropriate RKS supporting 
the network element. 

The IPCablecom Event Messages support billing and settlement for single-zone, intra-domain and inter-domain 
architectures. In most cases, the basic set of Event Messages, their associated attributes, and the triggers for the Event 
Message are identical for these three architectures. In the case of intra-domain and inter-domain architectures, 
additional triggers exist for a subset of the Event Messages. The IPCablecom Event Message specification details these 
requirements. 

For the purposes of settlements, each IPCablecom zone is divided into one or more logical Financial Entities. 
Settlements occur between Financial Entities. Each Financial Entity is identified by a Financial Entity ID (FEID). 
FEIDs are pre-assigned to every CMS and MGC in the IPCablecom network. A single CMS may be assigned at most 
one FEID. One or more CMSes may be assigned the same FEID. 

In the Intra-domain and Inter-domain cases, the originating and terminating CMSes exchange BCIDs and FEIDs. The 
originating CMS sends its BCID and FEID in the INVITE message. The terminating CMS sends its BCID and FEID in 
the first response to the INVITE message which is typically the 183 SDP. 



5.4 Real-Time Billing 



The billing system can be regarded as a functional block of the back office Operations Support System (OSS). The 
inputs to the billing system are the billing events and the outputs are the account balance and invoice. The billing 
system relates the billing events to the account balance by rating the events according to the pricing structure and other 
business logic. 
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Real-time Billing Systems relate the billing events to the account balance as events occur. As the billing system receives 
these real-time billing events, its rating engine rates the events and immediately posts balances. Real-time Billing 
Systems may be required to support advanced IPCablecom features such as pre-paid calling card, real-time fraud 
prevention, and real-time credit enforcement. 

The IPCablecom Event Message architecture can be used to support both real-time and batch billing systems. 

5.5 Real-Time and Batch Event Message Delivery 

Event Messages may be delivered to the RKS in real time as they are created. This enables support for a growing 
number of services that require purchase limits such as prepaid calling cards. 

As an alternative. Event Messages may be stored for some period of time and batched together before being sent to the 
RKS. This approach provides a more efficient use of network resources. 

5.6 Terminology and Concepts 

This clause defines terminology associated with usage data as it relates to IPCablecom Services. The concept of a "call" 
is well understood and used within the telecommunications marketplace today. A traditional telephony "call" involves 
establishing a dedicated, circuit- switched path between the calling and called parties. Packet- switched architectures, 
including IPCablecom, do not establish any such dedicated paths. To the contrary, the IPCablecom architecture assumes 
a shared medium between the head-end and the customer, as compared to the dedicated loop plant in traditional 
telephony; and during a traditional telephone call, as noted above, a circuit- switched "connection" is established 
between the parties, whereas packet switching is inherently "connectionless." All that said, the term "call" is sufficiently 
well entrenched that it will be used in the present document to refer to packet-mode voice communications between two 
parties over an IPCablecom network, even though in technical terms (as will be seen) there is little resemblance to a 
traditional telephone "call." It is envisioned that many new voice, video, data and other multimedia services will be 
developed to take advantage of the inherent extensibility of the IPCablecom architecture. These new services, which 
likely will not be derived from traditional telephony principals, will be based on the term transaction, which is more 
indicative of the data flows across the IPCablecom network. The Event Message structure is designed to be flexible and 
enable the addition of new IPCablecom services and features while maintaining backward compatibility with existing 
applications. Event Messages may support information required for billing of DOCSIS data services, video services, 
and the encapsulation of vendor specific proprietary data. 



Service 



Call 1 or Packet Call 2 or Packet 

Cable Transaction 1 Cable Transaction 2 



^ 



Event Event Event 

Message 1 Message 2 Message 3 



Figure 1: IPCablecom Terminology 
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5.6.1 Service 



A service is an individual or package of communications features a subscriber may select. A service is identified by a 
set of one or more "calls" or transactions that deliver the desired functionality to the subscriber. Examples of a service 
include: a voice communication between two local IPCablecom subscribers, a 3-way call, pay-per-view movie, and a 
web surfing session. A service may be instantaneous or persist over time. Service in the context of IPCablecom 1.5 
implies voice communications only and may not necessarily apply to the variety of other services such as Data, 
traditional IP, E-Commerce, etc. 

5.6.2 IPCablecom Transaction 

A IPCablecom transaction is a collection of events on the IPCablecom network when delivering a service to a 
subscriber. Event Messages for the same transaction are identified by one unique BCID (as described in table 39). For 
some services, multiple transactions may be required to provide information that is necessary to collect the total usage 
for the service. Multiple Event Messages may be required to track resources for each individual service used. A 
Transaction may persist over time. 

5.6.3 Call 

A call is an instance of user-initiated voice communication capabilities. In traditional telephony, a call is generally 
considered as the establishment of connectivity directly between two points: originating party and terminating party. In 
the IPCablecom context, as noted above, the communication between the parties is "connectionless" in the traditional 
sense. 

5.6.4 Event Message 

An Event Message is a set of data, representative of an event in the IPCablecom architecture that could be indicative of 
usage of one or more billable IPCablecom capabilities. An Event Message by itself may not be fully indicative of a 
customer's billable activities, but an Event Message correlated with other Event Messages builds the basis of a billable 
Usage Detail Record. 

5.6.5 Attribute 

An Event Message Attribute is a predefined data element described by an attribute definition and attribute type. 



5.7 Supporting Documentation 



A number of documents and specifications describe the IPCablecom project. The IPCablecom Architecture 
Framework [i.2] is the starting point for understanding the IPCablecom project and the various IPCablecom Interface 
Specifications, technical reports and other IPCablecom documents. 



6 IPCablecom objectives 

6.1 IPCablecom 1 .5 Required Services and Capabilities 

IPCablecom 1.5 provides basic voice capabilities and therefore shall support Event Messages for the following services. 
These services are described in more detail in clause 7 of the present document: 

• Interconnection with circuit- switched PSTN. 

Support for emergency services. 

nil assume outside directory service. 

Toll-free services. 



• 



• 
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Operator services. 

Call block service. 

Call waiting service. 

Call forwarding/call redirection services. 

Return call service. 

Repeat call service. 

Voice mail service. 

Message waiting indicator service (email/voice mail notification). 

Three-Way Call. 

Customer Originated Trace. 

6.2 Additional IPCablecom Supported Services and Capabilities 

The following represents a list of possible additional IPCablecom services that may be supported. The list, though 
meant as a rough guideline, is by no means comprehensive, and it is expected that as the scope of services grows, this 
list will be expanded. These services are not defined in more detail in the present document: 

Call transfer. 

Speed dialling. 

Caller name and number. 

Caller name and number privacy. 

Selective screening services. 

Pay-per-communication services. 

Distinctive notification (to identify callee in a multiple-party household). 

Priority notification (to prioritize incoming communications). 

Selective forwarding. 

Rejection (activate and deactivate). 

Teletype translation services. 

Multi-line hunt group services. 

Virtual second line (multiple lines). 

Alternate billing methods (collect, third number billed, credit card, pre-paid services, etc.). 

In addition, the following list represents a set of IPCablecom 1.5 services that may be supported by IPCablecom CMS 
network elements, however these services shall be supported by IPCablecom 1.5 RKS network elements. When these 
services are supported by an IPCablecom 1.5 compliant CMS, they shall be supported as defined in the present 
document. These services are described in more detail in clause 7 of the present document: 

• Account Code and Authorization Code. 
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6.2.1 IPCablecom Multimedia 



The IPCablecom Multimedia specification defines a service delivery framework that provides general-purpose QoS, 
event-based accounting, and security functionality founded upon the mechanisms defined in IPCablecom 1.5. It is 
defined in [i.l3]. The IPCablecom Multimedia specification extends the present document and the capabilities of the 
present Event Messages specification; refer to [i.l3] for more details. 

6.3 Assumptions 

The following assumptions have been made which apply to the entire document: 

• IPCablecom 1.5 does not specify the interface between an RKS and a billing system. 

• All IP based Intelligent Peripherals (these include Announcement Servers, for example) will be connected to 
the originating CMS or MGC. 

• IPCablecom 1.5 does not support Line Information Database (LIDB) queries. Calls requiring LIDB 
determination, such as calling card personal identification number validation, are sent directly to the PSTN. 

• IPCablecom 1.5 supports local number portability (LNP). Following information and references are applicable 
to LNP: 

1) Location Routing Number (LRN) identifies routing information for a ported called party number; and 
Jurisdiction Information Parameter (IIP) identifies the network element where the ported calling party 
number is currently getting the service from. The IIP parameter received in SS7 message is needed for 
billing settlement purpose. (References: GR-317-CORE, GR-2936-CORE, and GR-1100-CORE). 

2) The originating half determines if the caller is ported-in and the terminating half determines if the called 
party is ported-in. The CMS or MGC determines if a number is ported based on different data including 
a) provisioned data, b) signalling messages c) Number Portability data base. The source of Number 
Portability information is specified in Technical Requirements on Number portability systems [i.l8], 
table 8. 

• Non-IPCablecom network elements, such as those residing in the public switched telephone network (PSTN) 
to which an IPCablecom system may interconnect with, will NOT generate and send Event Messages to the 
RKS. 

• PSTN Intelligent Peripheral Event Messages are generated by the originating CMS. 

• IPCablecom 1.5 Event Messages currently only support messages for actual billable events. The present 
document does not specify messages related to provisioning of services by the operator of an IPCablecom 
network. The present document does support Event Messages for Subscriber service activation. The present 
document does not specify messages related to selection of an entity other than the IPCablecom network 
operator to handle off-network activities (e.g. inter-exchange communications). 

• The initiating party number and the terminating party number are the only two attributes defined in 
IPCablecom 1.5 that can be used to associate a subscriber with usage of network resources. 

• IPCablecom 1.5 supports interconnection to both Class 4 and Class 5 Switches. 

• IPCablecom supports a 91 1 Trunk Group. 

• IPCablecom 1.5 trusted network elements are expected to be pre-provisioned with a minimum set of data using 
a vendor-proprietary mechanism. Examples of this data may include: 

a) Element Type, identifying the element as a CMTS, CMS, or MGC. 

b) Element ID. 

c) A list of which Event Messages are required and which Event Messages are optional as defined by the 
cable operator. For each of these Event Messages, identify if the Event Messages are to: 

1) be transported to the RKS as a single Event Message in real-time; or 
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2) batched and transported to the RKS as multiple Event Messages at a later time; 

3) provide capability to configure both how many Event Messages are batched before being sent to 
the RKS. 

d) Number of days to keep Event Messages for short-term storage. 

e) Others. 

• Enable or disable Media_Alive Event Message, configure the frequency of Media_Alive message (suggested 
to 1 440 minutes, with being no Media_Alive Events). Event Messages Architecture. 

Figure 2 shows a representative IPCablecom Event Messages Architecture. By standardizing the transport, syntax and 
collection of appropriate Event Message attributes from a distributed set of network elements, the IPCablecom 
architecture provides a single reference point to interface to existing billing, settlement, reconciliation, and other 
systems. Note that only the shaded components are included within the scope of the IPCablecom 1.5 architecture. 
Interfaces between the RKS and the shaded IPCablecom network elements are within scope of IPCablecom 1.5. 
Interfaces between the RKS and back office servers or applications are NOT within the scope of IPCablecom 1.5. It 
should be understood that the back office servers and applications shown in figure 2 are representative, and are not 
mandated by the IPCablecom 1.5 architecture. 



IPCablecom Event Messages 
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^ •Batch Billing Systems 
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Figure 2: Representative IPCablecom Event Messages Architecture 

6.4 IPCablecom Event Message Collection 

Event Message collection occurs as follows: when trigger events occur [such as call signalling starts, activation of QoS 
service resources, call signalling stops, etc.], the relevant IPCablecom network element generates an Event Message. 
These messages may be sent immediately to the RKS, or a group of messages may be collected and sent at a later time. 
In either case, the actual time of the trigger event is reported allowing the back office applications to accurately 
calculate time-based resource usage. As these Event Messages are accumulated within the RKS, the network operator 
can then export them into their billing systems based on their business requirements. The data from multiple network 
elements are linked to a transaction [e.g. call] via a unique BCID, which can be leveraged for reconciliation and 
non-repudiation purposes. 



6.5 



IPCablecom Network Elements 



The IPCablecom architecture supports a system capable of creating, collecting, and delivering usage data from a subset 
of IPCablecom network elements to a cable operator's back office applications. Trusted IPCablecom 1.5 network 
elements that create Event Messages include the Call Management Server (CMS) and Cable Modem Termination 
System (CMTS), Media Gateway Controller (MGC). 
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The IPCablecom architecture contains trusted and untrusted network elements. Trusted network elements are typically 
located within a cable operator's facility and are controlled by the cable operator. Untrusted network elements are 
typically located within the consumer's home or outside of the cable operator's facility or exclusive control. In the 
IPCablecom 1.5 architecture, Event Messages are only accepted from trusted IPCablecom network elements. 

The IPCablecom Architecture Document [i.2] contains a detailed description of the IPCablecom network elements. A 
brief explanation of the IPCablecom network elements that will most likely generate IPCablecom Event Messages is 
listed in this clause for completeness. 

6.5.1 Call Management Server (CMS) 

The Call Management Server (CMS) provides signalling services necessary for voice communications. The primary 
purpose of the CMS is to establish standard "calls," as that term is used in the IPCablecom context. The media servers 
also provide support services for the media streams such as conference mixing bridges and announcement servers. 

The CMS shall create a BCID: 

• on receipt of an NCS- signalling NTFY message from an MTA; or 

• when an Event Message not associated with any call is generated. 

The CMS shall send the BCID and other data as defined in table 1 to the CMTS via the DQoS GateSet message as 
specified in the DQoS specification [3]. 

Table 1: IPCablecom Event Reporting Common Elements 



BCID (see table 39) 



IP address and port number of the primary RKS 



IP address and port number of the secondary RKS 



Flag indicating if CMTS should send Event Messages to the RKS in real-time 



The CMS shall generate the appropriate Event Messages as defined in the present document. 

6.5.2 Media Gateway Controller (MGC) 

The Media Gateway Controller (MGC) is the overall controller function of the PSTN gateway. It receives, mediates, 
and routes call signalling information between the IPCablecom and PSTN domains and it maintains and controls the 
overall call state for all calls connecting to and from the PSTN. It controls the Media Gateway function and 
communicates with the Signaling Gateway function via the MGC-SG protocol defined for the major protocol family in 
question, i.e. ISUP, In-band or TCAP. 

The MGC shall create a BCID on receipt of: 

• an SS7 lAM message; or 

• a TCGP NTFY with digits (operator services); 

• when an Event Message not associated with any call is generated. 

The MGC shall generate the appropriate Event Messages as defined in the present document. 

6.5.3 Cable Modem Termination System (CMTS) 

The Cable Modem Termination System terminates the connection from the cable modem on the customer premises into 
the IPCablecom network. The CMTS generates QoS Event Messages. QoS event messages are generated individually 
for both upstream and downstream bandwidth. 

The CMTS shall generate the appropriate Event Messages as defined in the present document. For all EM messages it 
generates other than Time_Change, the CMTS shall use the unique Billing-Correlation-ID assigned by the CMS and 
received from the CMS in the Event-Generation-Info object of the DQoS Gate-Set message as defined in [3]. See 
clause 8.16 for the generation of BCID in Time_Change events. 
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DOCSIS provides a mechanism by which multiple sessions can be placed on a single upstream service flow. DQoS 
supports this feature and refers to it as multiple grants per interval. There are two side affects to event messages when 
an MTA uses multiple grants per interval. The service flow ID (SFID) will be common among the events for all 
sessions that share that flow. The QoS Descriptor attribute relects the total bandwidth of all sessions using the flow. 



6.5.4 Record Keeping Server (RKS) 



The Record Keeping Server (RKS) is a trusted network element function. In many cases, for simplicity reasons, the 
RKS is depicted in the present document as a separate standalone element, but the present document does not preclude a 
CMS, Billing System, or other application from performing the RKS functionality. The RKS is the mediation layer 
between the call signalling and transport layer and the back-office applications. The RKS is expected to pre-process the 
data from the Call Signaling and Transport layer and present it to the back-office applications in the format and within 
the time constraints deemed necessary by the cable operator. 

The RKS also, at a minimum, is a short-term repository for IPCablecom Event Messages. It receives Event Messages 
from various trusted IPCablecom network elements. The RKS assembles the Event Messages into coherent sets, which 
are then made available to a usage-processing platform and potentially to several other back office systems. It acts as 
the demarcation point between the IPCablecom network and the back office applications. 

Figure 3 gives a representative RKS deployment for information only and does not imply an implementation 
requirement. 



Legend: 

Vendor-Defined Interface ■ _ 

PacketCable-Defined Interface 



RKS Hierarchy 



t 



Regional Data Center 




Figure 3: Example RKS Architecture 

The RKS is expected to perform the following functions: 

• The RKS shall receive Event Messages. 

• The RKS shall be capable of correlating all Event Messages related to an individual call and have an 
extensible output to meet the needs of the downstream applications. 

• The RKS shall assemble Events and Determine Completeness. This shall include the capability to distinguish 
Event Messages, and recognize when a complete set, representing a coherent set of billing data is available for 
transport to the back office system. 
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• The RKS shall provide interface network functions that require real time or near real time based on priority 
and where messages are being sent, as defined in clause 8. For example, a call may be sent real-time and a 
report may be sent at night. The correlation process shall be user definable to support the various call events 
defined herein and defined in the future. 

• The RKS shall have the ability to store the Event Messages for at least one week or until sent to the other back 
office systems and successful receipt is acknowledged from those systems. 

• The RKS shall have the ability to dump the Event Messages to some other type of offline storage device on a 
regular basis (CD, tape, or other media) for retrieval and regulatory purposes. 

The following list deals with other possible capabilities of an RKS. They are therefore beyond the scope of the 
requirements of this current document, and are included here for informational use only. Decisions on these optional 
requirements will be based upon the cable operator response to many regulatory and business variables. 

An RKS-RKS security interface may be required. IPCablecom 1.5 does not define this interface. The security 
interface between the RKS and other IPCablecom trusted network elements is defined in [2] . 

The RKS may support Backup and Recovery. This includes a nominal ability to restore the state and contents 
of billing data in the event of application or platform failures. 

The RKS may support distribution of billing data to all appropriate systems. This includes the implementation 
of a protocol that ensures data integrity and reliability on the usage collator interface. 

The RKS may support monitoring and reporting. This includes the ability to produce and send alarms to a 
network management system, and create various audit and measurement reports. 

The RKS may allow remote testing and maintenance capability. 

The RKS may support a Service Creation Environment. 

The RKS may support user defined fault handling in the case of incomplete Event Messages or other such 
anomalies. 

The RKS may support multiple downstream applications, and various transport methodologies. 

The RKS may support full auditability of data and processes. 

The RKS may support a user definable long-term storage mechanism. 

The RKS may support disaster planning and recovery processing. 

6.6 General IPCablecom Network Element Requirements 

This clause lists requirements placed on the IPCablecom network elements. 

The CMS, CMTS, and MGC shall create a security relationship with each RKS that these network elements will send 
Event Messages as defined in the IPCablecom Security Specification [2] . 

The CMS shall support multiple sets of primary and secondary RKSes, which might be required in cases in which total 
Event Message traffic exceeds the throughput capability of a single RKS. 

For each call, the CMS or the MGC shall create a unique BCID, identify the primary and secondary RKS and determine 
whether the Event Messages are to be delivered in real time or batched and sent at a later time. 

• The trusted IPCablecom network elements that generate Event Messages shall timestamp Event Messages in 
1 millisecond granularity ±100 milliseconds based on information reported by network time sources such as 
edge devices (Clients and Gateways). 

• All IPCablecom network elements that generate Event Messages shall synchronize their clocks at least once 
per hour to a network clock source. This synchronization shall assure the reporting device's own clock remains 
within +100 milliseconds real time of the last synchronization value. 
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IPCablecom network elements that generate Event Messages shall support Network Time Protocol (NT?) time 
synchronization as defined in [10]. 

The IPCablecom network elements shall support transport to a primary RKS and failover to a secondary RKS 
when communication with the primary RKS fails for any reason (including situations where the primary RKS 
becomes inoperable). 

IPCablecom network elements shall support the transport of a single Event Message as well as a batch of 
Event Messages (batch mode = multiple Event Message per single Radium message). 

Each trusted IPCablecom network element that generates an Event Message shall identify itself with a static, 
unique element ID. 

Implementations that combine CMS and MGC functionality may share a single element ID. Event Messages 
generated by a combined CMS/MGC shall indicate which IPCablecom functional element (e.g. MGC or CMS) 
initiated the message using the Element_Type field in the EM_Header. 



6.7 Event Message Interfaces 



This clause describes the interfaces between the IPCablecom network elements that are involved in the Event Messages 
process. It should be noted that additional requirements are imposed on these by other IPCablecom specifications and 
that the requirements listed in the present document are specific to Event Messages. It should also be noted that 
additional requirements are specified for these interfaces and these IPCablecom network elements in other clauses of 
the present document. 
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Figure 4: Event Message Billing Interfaces 

6.7.1 CMS to CMTS (pkt-emr) 

The CMS to CMTS interface is defined by the IPCablecom DQoS protocol [3]. 

The CMS sends the BCID and other data as defined in table 1 to the CMTS via the DQoS GateSet message as specified 
in the DQoS specification [3]. 

6.7.2 CMS to MGC (pkt-em2) 

The CMS to MGC interface is defined by the IPCablecom CMSS specification [7]. The CMS and MGC exchange 
originating/terminating information such as BCID, FEID, etc. across this interface as defined in [7]. 

6.7.3 CMS to RKS (pkt-em3) 

The CMS to RKS interface is defined by the IPCablecom security specification [2] and also by the Event Message 
transport and syntax rules defined in the present document. 
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6.7.4 CMTS to RKS (pkt-em4) 



The CMTS to RKS interface is defined by the IPCablecom security specification [2] and by the Event Message 
transport and syntax rules defined in the present document. 

6.7.5 MGC to RKS (pkt-em5) 

The MGC to RKS interface is defined by the IPCablecom Security specification [2] and by the Event Message transport 
and syntax rules defined in the present document. 

6.7.6 CMS to CMS (pkt-em6) 

The CMS to CMS interface is defined by the IPCablecom CMSS specification [7]. The originating CMS and 
terminating CMS exchange originating/terminating information such as BCID, FEID, etc., across this interface as 
defined in [7]. 



6.7.7 Security Requirements 



When the network IPSec Security Associations are established, security keys shall be created and exchanged between 
each RKS (primary, secondary, etc.) and every CMS, CMTS, and MGC that will send Event Messages to any of those 
RKSes. The Event Messages are sent from the CMS, CMTS, and MGC to the RKS using one of the supported transport 
mechanisms, each of which it must be possible to secure with IPSec. Refer to the IPCablecom Security specification [2] 
for a detailed description of the security requirements for the IPCablecom Event Message interfaces. 



7 IPCablecom services and their associated event 

messages 

This clause defines the supported IPCablecom 1.5 Services and their associated Event Messages. Although many of the 
IPCablecom 1.5 services can be billed using the Event Messages and attributes defined in the present document, the 
services described in this clause are currently limited to IPCablecom 1.5 services. 

In order to identify appropriate Event Messages required for each service, representative call flows were developed for 
IPCablecom 1.5 basic call configurations. The IPCablecom Call Flow documents [i.4], [i.5], [i.6], provide a description 
of the call configuration along with any assumptions made about a specific service and an example call flow. It is not 
the intention of these call flow documents to limit the realization of any of these services to any specific 
implementation. 

7.1 IPCablecom Call Configurations 

This clause describes the three basic IPCablecom 1.5 call configurations: On-Net to On-Net, On-Net to Off-Net, and 
Off-Net to On-Net. A required minimum set of Event Messages shall be generated for each of these three basic call 
configurations. If specific services are initiated along with the basic call, then refer to clause 7.2 for a list of additional 
Event Messages for these specific services. 

7.1.1 On-Net to On-Net Call Configuration 

A single-zone On-Net to On-Net call is within a single cable operator's network, using two different MTAs that are both 
connected to the same CMS. For IPCablecom 1.5, it is assumed that both the originating and terminating MTAs are 
using the same CMS and possibly two different CMTSes. 

Refer to the IPCablecom Call Flow document [i.4] for a complete description of an example single-zone On-Net to On- 
Net call configuration including an example call flow showing the triggers for these Event Messages. 

Both intra-domain and inter-domain On-Net to On-Net call configurations use two different MTAs that are both 
connected to two different CMSes. 
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For any On-Net to On-Net call configuration, the originating half and the terminating half of the call shall each generate 
a complete set of Event Messages. 

Table 2: On-Net to On-Net Call Configuration 



Event Message 


Required or 
Optional 


Comments 


Database Query 





If LNP is required 


Signaling Start 


R 


CMS is starting signalling to support a call start 


QoS Reserve 


R 


CMTS is reserving QoS 


QoS Commit 


R 


CMTS is committing QoS 


lntelligent_Peripheral_Usage_Start 





E.g. if an announcement is needed 


Intelligent Peripheral Usage Stop 





E.g. if an announcement is needed 


Call Answer 


R 


Indicates start of media stream 


Call Disconnect 


R 


Indicates termination of media steam 


QoS Release 


R 


CMTS is releasing QoS 


Signaling_Stop 


R 


Signaling for the service is complete 


Media Statistics 





Media stream statistics reported by the gateway 



7.1 .2 On-Net to Off-Net Call Configuration (Outgoing PSTN interconnect) 

The only Off-Net interconnection supported by IPCablecom 1.5 is to the PSTN. Therefore the CMS sends all Off-Net 
calls to the PSTN. The Interconnect_Start Event Message identifies the type of Off-Net trunk, for example SS7/FG-D 
trunks, Type 1/DTMF trunks or some other type of trunks as required. The Off-Net call (i.e. non-special access codes 
calls e.g. 800, 900, Nil, etc.) may require an LNP query. The CMS shall generate a database query Event Message each 
time a LNP database is accessed (regardless of whether this query is requested from a PSTN database or IP database). 

Refer to the IPCablecom Call Flow document [i.5] for a complete description of this call configuration including an 
example call flow showing the triggers for these Event Messages. 

For any On-Net to Off-Net call configuration, the originating half and the terminating half of the call shall each 
generate a complete set of Event Messages. 

Table 3: On-Net to Off-Net Call Configuration 



Event Message 


Required or 
Optional 


Comments 


Database_Query 





If LNP is Required 


Signaling Start 


R 


Starting signalling to support a call start 


QoS Reserve 


R 


CMTS reserves QoS 


QoS Commit 


R 


CMTS commits QoS 


Intelligent Peripheral Usage Start 





E.g. if an announcement is needed 


Intelligent Peripheral Usage Stop 





E.g. if an announcement is needed 


Interconnect Start 


R 


For call setup 


Call Answer 


R 


Indicates start of media stream 


Call Disconnect 


R 


Indicates termination of media steam 


Interconnect Stop 


R 


For call tear-down 


QoS Release 


R 


CMTS releases bandwidth 


Signaling Stop 


R 


Indicates end of signalling 


Media Statistics 





Media stream statistics reported by the gateway 



7.1 .3 Off-Net to On-Net Service (Incoming PSTN Interconnection) 

The CMS receives calls that are incoming from other entities and establishes communications with the MTA on the 
cable operator's network. For IPCablecom Release 1.5, it is assumed that all incoming calls are from the PSTN. 

Refer to the IPCablecom Call Flow document [i.6] for a complete description of this call configuration including an 
example call flow showing the triggers for these Event Messages. 

For any Off-Net to On-Net call configuration, the originating half and the terminating half of the call shall each 
generate a complete set of Event Messages. 
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Table 4: Off-Net to On-Net Call Configuration 



Event Message 


Required or 
Optional 


Comments 


Signaling Start 


R 


Starting signalling to service a request to start a call 


Interconnect Start 


R 


For call setup 


QoS Reserve 


R 


CMTS reserves bandwidth 


QoS Commit 


R 


CMTS commits bandwidth 


Intelligent Peripheral Usage Start 





E.g. if an announcement is needed 


Intelligent Peripheral Usage Stop 





E.g. if an announcement is needed. 


Call Answer 


R 


Indicates start of media stream 


Call Disconnect 


R 


Indicates termination of media steam 


Interconnect Stop 


R 


For call tear-down 


QoS Release 


R 


CMTS releases bandwidth. 


Signaling Stop 


R 


Indicates end of signalling 


Media Statistics 





Media stream statistics reported by the gateway 



7.2 Specific Services 



A basic set of Event Messages shall be generated based on the type of call configuration: On-Net to On-Net, On-Net to 
Off-Net, Off-Net to On-Net. The basic set of Event Messages is described in clause 7.1. 

This clause describes additional Event Messages that shall be generated along with the basic set in order to describe 
specific IPCablecom 1.5 services. This clause also describes optional Event Messages that may be generated along with 
the basic set and any additional required Event Messages. These additional required and optional Event Messages are 
identified in the tables in this clause. It is expected that these additional Event Messages will be able to be generated 
regardless of the particular implementation of the service. 

7.2.1 911 Service 

A 91 1 call follows the standard On-Net to Off-Net Event Message flow described above in clause 7.1.2. 

911 calls require special treatment. In IPCablecom Release 1.5, it is assumed that the cable operator sends 911 calls to 
the PSTN on a special trunk. The Trunk Group ID is captured in the Interconnect_Start and Interconnect_Stop Event 
Messages, and it is assumed that the RKS or some element downstream of the RKS has the capability of inferring this 
trunk group type from that unique Trunk Group ID. 

No additional Event Messages are required beyond the basic ones listed for an On-Net to Off-Net call in clause 7.1.2. 

7.2.2 Other Nil Services (311, 411, 611) 

These calls are identical to the 91 1 call both from a call flow and Event Message perspective. The determination of 
whether to bill or not can be performed at the Billing System based on the "Called Party Number" attribute. For 
example, charges for calls to 41 1 for directory assistance may be different than charges for 91 1 emergency calls, which 
are free, but the Event Messages, which capture the usage for both types of services, are the same. They would differ 
only in the content of specific attribute values such as the Called_Party_Number (411 vs. 911) within the Call_ Answer 
Event Message. The billing system is expected to make a determination as to how much to bill the customer based on 
these attributes together with other factors such as whether the call is completed or not. 

7.2.3 Toil-Free Services 

Toil-Free Services follow the standard On-Net to Off-Net Event Message flow described above in clause 7.1.2. In 
IPCablecom 1.5, toll-free calls can be handled two ways: 

• Send all Toll-free calls to the PSTN on a special trunk. The call is treated exactly like the 91 1 case discussed in 
clause 7.2.1 in terms of Event Messages, meaning that no additional Event Messages are required. 

• Initiate a query to the toll-free SCP (in IP or PSTN) and, depending on the specified Carrier Identification 
Code, route the call to the appropriate network. A Database_Query Event Message shall be generated to record 
the query to the toll-free database. 
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Table 5: Toil-Free Services 



Additional Event Messages 


Required or 
Optional 


Comments 


Database Query 


R 


Not used for Scenario 1 but required for Scenario 2 



7.2.4 Operator Services 



Operator Services follow the standard On-Net to Off-Net Event Message configuration described above in clause 7.1.2. 
There are no new additional Event Messages beyond those already described for the On-Net to Off-Net calls in that 
clause. The CMS sends that call to the designated Operator Service Provider using the PSTN. There may be multiple 
Operator Service Providers with which the cable operator has contracts. The caller just dials "0." 

The CMS generates an event identifying that call as 0- (denoting the single digit "0" dialled without any subsequent 
digits) with "0" in the Called number field. The CMS replaces the "0" in the Called Number field with the number of 
the Operator Service Provider (OSP). These parameters are sent to PSTN so that call can be sent via PSTN to the OSP. 
It is assumed dedicated private lines to the OSP from each IP-switch are impractical and expensive for cable operator 
and not considered as an option. 

For the purposes of IPCablecom 1.5, it is assumed that operator services encompasses only 0- services. 0+ service, in 
which the customer keys the dialled number in together with the initial "0", is not supported in IPCablecom 1.5. 

7.2.5 Call Block Service 

Event Messages are generated for Call Block Service only if the CMS blocks a call. Call Blocking is supported by all of 
the three basic call configurations: On-Net to On-Net, On-Net to Off-Net, and Off-Net to On-Net. 

The CMS can block calls depending on the policies laid out by the cable operator. For example, the cable operator may 
allow the end-user to block all 900 calls at the user's request. As another example, the cable operator may recognize 
some calls as fraudulent and block those fraudulent calls. In this case an Event Message needs to be generated with 
some reason attributes as to why the call was blocked. In addition, depending on the type of blockage, the cable 
operator may desire to play an appropriate announcement (e.g. "Sorry your time is up ..."). The CMS may initiate 
another call to the Announcement Server via the PSTN and play it to the caller. A series of Event Messages will be 
generated for this call, using the same BCID as the standard Event Messages associated with the off-hook, dialling, etc., 
which is not expected to be used for billing this call to the end-user. 

Table 6: Call Block Service 



Additional Event Messages 


Required or Optional 


Comments 


Service Instance 


R 


None 


Intelligent Peripheral Usage Start 







lntelligent_Peripheral_Usage_Stop 








7.2.6 Call Waiting Service 



At any given time the caller may be talking and will hear the call waiting tone when another call is incoming. It is 
understood that at some point prior to this call, the called party subscribed to call waiting service. The called party can 
switch back and forth between the two calls by using the flash hook. Call Waiting can be supported by any of the three 
basic call configurations: On-Net to On-Net, On-Net to Off-Net, and Off-Net to On-Net. 

The call flow is as follows: 

• There is an existing call to a number connected via the MTA/CMTS/CMS. Another call attempt is made to 
that number, the CMS: 

Verifies that an existing call is already in progress; 

Checks its internal database to verify whether the called party has subscribed to Call Waiting, if yes: 

Establishes a voice connection to the Announcement Server (which will play the call waiting tone); 
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Creates a Event Message indicating that Call Waiting is being initiated; 

Mixes the two voice calls (the currently established voice call and the Call Waiting tone voice call) so 
that the called party can hear the call waiting tone. 

It is assumed that Call Waiting only supports two calls (one active and the other on hold) in IPCablecom 1.5. The call 
on hold will not be connected to any announcement server. 

Both of the calls between which the subscriber is switching generate a complete set of Event Messages on their own as 
detailed in clauses 7.1.2 and 7.1.3, but there may also be three additional Event Messages associated with this instance 
of Call Waiting, as detailed below. If the Announcement Server is located on the PSTN, then the previously discussed 
Call_Answer and Call_Disconnect Event Messages are generated for this call. 

Table 7: Call Waiting Service 



Event Message 


Required or 
Optional 


Comments 


lnterconnect_Start 





Required only if Announcement Server for Call Waiting 
tone is Off-Net on PSTN 


lnterconnect_Stop 





Required only if Announcement Server for Call Waiting 
tone is Off-Net 


Intelligent Peripheral Usage Start 





Required only if Announcement Server On-Net 


Intelligent Peripheral Usage Stop 





Required only if Announcement Server On-Net 


Service Instance 


R 


None 



7.2.7 Call Forwarding Service 

Call Forwarding Service applies only to calls terminating On-Net as described in clauses 7.1.1 and 7.1.3. 

The CMS gets notification that a call needs to be completed to a specific dialled number/end device. The CMS checks 
its internal database and determines that the called number has subscribed to Call Forwarding, Call Forwarding is 
currently active, and the forwarding number is XYZ. The CMS initiates another call to the forwarded number on behalf 
of the original calling party. The CMS shall generate a Service_Instance Event Message with the 
Calling_Party_Number attribute containing the original calling party number, the Charge_Number attribute containing 
the original called party number (the party number of the subscriber who has call forwarding service enabled), and the 
Called_Party_Number containing the forwarded number XYZ. Event Messages are generated for the fact that a Call 
Forwarding service instance was initiated. The BCID for this leg is different than the first call. The rationale for using 
the Related BCID as the common identifier for call forwarding is that it may be desirable to flag calls made 
automatically by invocation of call forwarding on the subscriber's monthly statement in order to make it clear the reason 
those calls were placed. For all purposes the original call and the forwarded call are two different billable calls. This 
will require the RKS to replace the Calling Party Number with the value of the Charge Number for the forwarded call's 
AMA record. The Calling_Party_Number attribute in the Service_Instance Event Messages is consistent with Telcordia 
Technologies' GR-580-CORE [i.l5], GR-586-CORE [i.l6] call forwarding specifications and the GR-317-CORE [i.l7] 
specification. 

Table 8: Call Forwarding Service 



Event Message 


Required or Optional 


Comments 


Service Instance 


R 


None 



7.2.8 Return Call Service 

This service applies only to calls originating On-Net, described in clauses 7.1.1 and 7.1.2. The CMS shall keep a 
register with the Calling Party Number of the last call. 

Return Call Service returns the last call that was made to an MTA. Upon instantiation of Return Call feature, the CMS 
initiates another call with the Calling Party Number of the last call, retrieved from the register just described, as the 
Dialled number. Event Messages are generated for the fact that the Return Call feature was initiated, using the BCID of 
this call. If the Calling Party Number of the last call had Caller ID privacy restrictions, then CMS may conference in a 
recording from an announcement server saying that this call cannot be completed. 
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Table 9: Return Call Service 



Event Message 


Required or 
Optional 


Comments 


Service Instance 


R 


None 


lnterconnect_Start 





Required only if Announcement Server for delivering the 
Message indicating reason Return Call cannot be activated is 
Off-Net on PSTN. 


lnterconnect_Stop 





Required only if Announcement Server for delivering the 
Message indicating reason Return Call cannot be activated is 
Off-Net on PSTN. 


lntelligent_Peripheral_Usage_Start 





Required only if Announcement Server for delivering the 
Message indicating reason Return Call cannot be activated is 
On-Net. 


lntelligent_Peripheral_Usage_Stop 





Required only if Announcement Server for delivering the 
Message indicating reason Return Call cannot be activated is 
On-Net. 



7.2.9 Repeat Call Service 

Repeat Call Service applies only to calls terminating On-Net as described in clauses 7.1.1 and 7.1.3. 

Repeat Call can be initiated when the caller dials a number and gets a busy signal. With this feature the caller dials a 
special pre-determined string of digits (*66 in the United States of America) which then instructs the network to keep 
polling the called and calling party and when both free, establish the communication. In IPCablecom 1.5, the originating 
CMS will keep trying to establish communications to the called number for a pre-determined amount of time. 

Table 10: Repeat Call Service 



Event Message 


Required or 
Optional 


Comments 


Service Instance 


R 


None 


lnterconnect_Start 





Required if Announcement Server for delivering the Message 
indicating reason Repeat Call cannot be activated is Off-Net on 
PSTN. 


lnterconnect_Stop 





Required only if the appropriate lnterconnect_Start was activated. 


Intelligent Peripheral Usage 
Start 





Required only if Announcement Server for delivering the Message 
indicating reason Repeat Call cannot be activated is On-Net. 


lntelligent_Peripheral_Usage 
Stop 





Required only if Announcement Server for delivering the Message 
indicating reason Repeat Call cannot be activated is On-Net. 



NOTE: There may be multiple Interconnect_Start and Stops capturing the multiple different times the originating 
CMS tries to make an Off-Net call to try to complete a Repeat Call request. 

7.2. 1 Voice Mail Service 

Voice Mail Service only applies to calls terminating On-Net, described in clauses 7.1.1 and 7.1.3. 

It is assumed that the voice mail server will be located Off-Net for IPCablecom 1.5. It is therefore assumed if voicemail 
billing is usage sensitive, that connections to the Off-Net voicemail system will be counted in the same way whether 
they are voicemail messages being left for the subscriber (deposit) or calls to retrieve the messages on the voicemail 
server. 

Voice mail deposit and retrieval scenarios are treated as separate transactions that have associated Event Messages. 
Event Messages for voice mail deposit look like a standard On-Net to Off-Net call. When the call is transferred to the 
Voice Mail Server, the Routing Number shall be captured and populated with the Voice Mail Server Address. 

The connection time to the Voice Mail Server may also be derived through the standard On-Net to Off-Net Event 
Messages. Since the Voice Mail Server is located Off-Net, Event Messages for voice mail retrieval may only be 
generated if the retrieval is initiated from a device within the cable operator's network (e.g. On-Net to Off-Net call). 
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7.2.1 1 Message Waiting Indicator Service 



It is assumed that an Off-Net voicemail system is used as described in clause 7.2.10. Because it seems unreasonable for 
the CMS to have to place a separate call to the Off-Net system each time a voicemail subscriber goes off-hook, it is 
assumed that a mechanism exists which allows the Off-Net voicemail system pass the information to the CMS 
indicating which subscribers have voicemail waiting. A further assumption is that the MTA is capable of delivering the 
audible stutter-tone message-waiting indicator to the subscriber's MTA port going off-hook, on the command of the 
CMS. 

Under the scenario described in the assumptions clause, and given the fact that billing is not based on any per use 
delivery of the stutter tone, there are no Event Messages required for this service. Billing is based on a combination of 
information obtained from the Voicemail send/retrieve Event Messages discussed in clause 7.2.10 and provisioning 
information indicating when a subscriber has signed up for voicemail services. 



7.2. 1 2 Three-Way Call Service 



The Three-Way Call Service allows a subscriber to add a third party to an active call. Three-Way Call Service applies to 
the originating and terminating CMS. To operate Three-Way Call Service, the subscriber dials the first call party. While 
on the first call, the subscriber presses the switch hook or flash key to place the first party on hold, and, after listening 
for a dial tone, dials a second party number. The second party answers, the subscriber may speak privately or create a 
Three-Way Call by depressing the hook switch or pressing the flash key once again to merge the two calls. The 
Three-Way Call Service is then initiated and the Servicejnstance Event Message is generated by the subscriber's CMS. 

Table 1 1 : Three-Way Call Service 



Event Message 


Required or 
Optional 


Comments 


Service_lnstance 


R 


If the Three-Way Call Service is supported by the CMS, the CMS shall generate a 
Service Instance Event Message when the Three-Way Call service is initiated. 



7.2. 1 3 Customer Originated Trace Service 

The Customer Originated Trace Service (COT) allows subscribers to activate an immediate trace on an annoyance or 
nuisance call. After a nuisance call is terminated, a subscriber who wishes to trace the call picks up the handset and goes 
off-hook, listens to dial tone, and then dials the Customer Originated Trace activation code (for example, in the United 
States, the Customer Originated Trace activation code is *57). 

Table 12: Customer Originated Trace Service 



Event IVIessage 


Required or 
Optional 


Comments 


Service_Activation 


R 


If the Customer Originated Trace Service is supported by the CMS, the CMS shall 
generate a Service_Activation Event Message when the Customer Originated 
Trace Service is initiated. 



Note that when the COT Service is activated, it only appHes to one call (the last call received by the subscriber), and no 
Service_Deactivation Event Message is generated. 

7.2.14 Account Code and Authorization Code Service 

The Account Code and Authorization Code Service defines two service capabilities as one service in support of account 
& authorization codes. The account and authorization codes may be used by Business Support Systems (BSS) to apply 
various accounting & charging rules based on the codes. 

Account codes allow call charging to user projects, departments or special accounts, etc. A subscriber may activate the 
Account Code service capability when initiating a call (usually a long distance call) in order to have the call accounting 
recorded under a special project or account. The account code may then be used in the BSS systems for various 
purposes including call accounting & charging; it is usually not subject to verification by the CMS. 
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Authorization codes provide the capabiHty for a subscriber to override call restrictions for a single call. A subscriber 
may be restricted from making toll calls and may decide to activate the Authorization Code service capability when 
placing a long distance phone call in order to remove the default call restrictions for that one call. The subscriber can 
typically override the restriction by dialling an authorization code that grants enough privileges to make long distance 
calls. The Authorization Code Service capability is used in a business group environment where multiple authorization 
codes may be assigned to grant various call privileges. Some authorization codes may be used to logically segment a 
given account code. 

The Telcordia Technologies General Requirements document GR-605-CORE [i.l4] defines multiple mechanisms for 
"Authorization Codes for Automatic Flexible Routing (AFR) and Account Codes for Basic Business Group and AFR". 
A CMS may implement one or more of the mechanisms defined in GR-605-CORE [i.l4]. However, IPCablecom CMS 
network elements shall support the generation of Service_Instance Event Messages and report the account or 
authorization code entered by the subscriber as defined in the present document if any GR-605-CORE mechanisms are 
supported. 

Table 13: Account Code and Authorization Code Service 



Event IVIessage 


Required or 
Optional 


Comments 


Service_lnstance 


R 


If the Account Code and Authorization Code Service is supported by 
the CIVIS, the CIVIS shall generate a Service_lnstance Event Message 
when either the account or authorization code service capability is 
initiated. 



The CMS shall generate a Service_Instance Event Message when the Account Code and Authorization Code Service is 
initiated even when the dialled code is invalid and the call is not successfully made. The Call_Termination_Cause 
attribute shall be present in the Service_Instance Event Message for this service and it shall be encoded as defined in 
(GR-1100-CORE [6] table 235). This attribute indicates whether the service is successfully completed or the reason for 
the service failure (for e.g. the dialled code provided by the subscriber is not authorized or invalid). A successful call 
completion code reported in the Service_Instance Event Message only means that the Account Code and Authorization 
Code Service is successfully attempted and that the call signalling may proceed (other errors could occur resulting in a 
call failure during the call setup which may be reported in other Event Messages, like the Signaling_Stop Event 
Message for example). 



8 IPCablecom event message structure 

This clause describes the various Event Messages, together with their associated list of attributes. Refer to clause 9 for a 
detailed description of the attributes described in this clause. Refer to clause 7 for a detailed description of the services 
and their associated Event Messages. 

The description of each event message in this clause includes: 

• A summary of the EM purpose and conditions under which it is sent. 

• Mandatory requirements for triggers that cause the EM to be created and time-stamped during a call that is 
completely set up and terminates normally. Throughout clause 8, the time-stamp triggers for each EM are 
clearly defined. When a time-stamp requirement exists for an Event Message, there is an assumption that the 
event message will be generated as well, however when the message is actually transmitted depends on 
whether the NE is operating in immediate or batch mode (see clause 6.4). 

• A table showing mandatory and optional attributes in the EM. 

Note that, even though only mandatory EM trigger requirements for normal completed calls are specified, the NEs are 
expected to implement reasonable triggers for all call and exception scenarios. Additionally, NEs are expected to 
implement reasonable triggers if they have not implemented all IPCablecom interfaces (for example, if CMS-to-CMS 
signalling is not used for CMS to MGC communication). 
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The following tables show the association between IPCablecom 1.5 services, supported by the aforementioned call 
configurations, and proposed Event Messages that may be generated for each service. Voice communications services 
that IPCablecom 1.5 provides are based on three main call configurations: 

• On-Net to On-Net. 

• On-Net to Off-Net. 

• Off-Net to On-Net. 

Table 14 provides a list of IPCablecom Event Messages defined in the present document. More than one set of Event 
Messages may be generated during a particular service instance. 

Table 14: IPCablecom Event Message Summary 



Event Message 
ID 


IPCablecom Event Message 


Description 





Reserved 




1 


Signaling_Start 


Start of signalling for originating or terminating part of the 
call 


2 


Signaling_Stop 


Stop of signalling for originating or terminating part of the 
call 


3 


Database_Query 


An inquiry into an external database; for example a toll-free 
number database 


4 


lntelligent_Peripheral_Usage_Start 


Deferred 


5 


lntelligent_Peripheral_Usage_Stop 


Deferred 


6 


Service Instance 


Indicates an occurrence of a service 


7 


QoS_Reserve 


Reservation of QoS for originating or terminating part of 
the call 


8 


QoS_Release 


Release of QoS for originating or terminating part of the 
call 


9 


Service Activation 


Indicates a subscriber has activated a service 


10 


Service Deactivation 


Indicates a subscriber has deactivated a service 


11 


l\/ledia_Report 


Indicates a change in media session information. 


12 


Signaljnstance 


Indicates an NCS signal instance 


13 


lnterconnect_(Signaling)_Start 


Start of network interconnect signalling (between 
IPCablecom and PSTN) for originating or terminating part 
of the call 


14 


lnterconnect_(Signaling)_Stop 


Stop of network interconnect signalling (between 
IPCablecom and PSTN) for originating or terminating part 
of the call 


15 


Call_Answer 


Indicates that all network resources for have been 
allocated for originating or terminating part of the call 


16 


Call_Disconnect 


Indicates that all network resources for have been released 
for originating or terminating part of the call 


17 


Time_Change 


Indicates time change on a network element 


19 


QoS_Commit 


Commitment of QoS for originating or terminating part of 
the call 


20 


IVIedia Alive 


Indicates if the call is still active 


21 


Conference_Party_Change 


A party is added, placed on hold, or retrieved from hold in 
a call involving multiple parties. 


22 


IVIedia Statistics 


Media stream statistics reported by the gateway 


23 


Surveillance_Stop 


Indicates end of call content and/or call data. Generally, 
this will mean the end of a call. However, this can also 
indicate that call content and/or call data can no longer be 
intercepted (e.g. a call has been forwarded to another 
service provider's network and cannot be intercepted). 


24 


Redirection 


Indicates that a call involving the surveillance subject has 
been redirected by either the surveillance subject or an 
associate in those scenarios where a Service_lnstance is 
not sent. 


31-39 


Reserved 


Reserved for IPCablecom Multimedia 
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The Signaling_Start, Signaling_Stop, Call_Answer, and Call_Disconnect messages are important for accounting 
purposes and tracking the signalling overhead for media session establishment. The following are some assumptions on 
how these messages will be used: 

• Signaling_Start and Signaling_Stop messages bracket the timeframe during which the CMS or MGC is 
processing dialled digits, performing signalling, and maintaining state for a call. Thus, the time-stamp on a 
Signaling_Start is time-stamped as early in the flow as possible on both the originating and terminating side 
after the message containing routable digits from the originator. A routable set of digits can be defined as a set 
of digits that are collected by the MTA matching the digit map, and will trigger call routing processing (e.g. 
*69 would not be considered routable digits, but 00 would). The time-stamp on the Signaling_Stop is time 
stamped when signalling for the call is completed, generally when a DLCX is sent to an endpoint. 

• A Signaling_Stop is generated if and only if a Signaling_Start was generated. Under normal circumstances, an 
RKS can expect a Signaling_Start and Signaling_Stop message for each set of event messages it receives for a 
specific BCID. 

• Call_Answer and Call_Disconnect messages bracket the time-frame during which 2-way media path is active. 
The time-stamps on these messages are used to calculate call time and duration for any calls that have usage 
billing. The time-stamp on the Call_Answer will closely match the time at which the terminating party goes 
off-hook, and the time-stamp on the Call_Disconnect will closely match the time at which the media path is 
torn down. 

• A Call_Disconnect is generated if and only if a Call_Answer was generated. Existence of these two EMs in a 
set of EMs for a BCID indicates that all the conditions for a 2-way media path were met. 

• The Called_Party_Number in Signaling_Start is the E.164 number of the terminating party. This number is 
intended to capture the destination of the call as specified by the originator. It often indicates the dialled-digits 
from the originator (e.g. for the 3 digit calls like 911,411, this attribute captures this 3 digit number). 
However, there are several cases in which this field does not reflect the actual input of the user (e.g. in case of 
features like speed dial, it is populated with the digits configured for the speed dial digits). A few examples: 

1) Subscriber is in area code 972 and has 7 digit dial plan. When the subscriber dials 234-1234, the 
Called_Party_Number in Signaling_Start is populated with the 10 digit number including the area code, 
9722341234. 

2) Subscriber has speed dial feature and configured 1 1 to 972-234-1234. When the subscriber dials 1 1#, the 
Called_Party_Number in Signaling_Start is populated with the 10 digit number configured for the speed 
dial 11, 9722341234. 

3) When a subscriber dials 911 for emergency call, the Called_Party_Number in Signaling_Start is 
populated with 3 digit 911. 

4) When the subscriber dials 1-919-234-1234, the Called_Party_Number in Signaling_Start is populated 
with the 10 digit number without the prefix, 9192341234. 

5) When the subscriber dials a dial around code, 1010288, and then dials 919-234-1234, the 
Called_Party_Number in Signaling_Start is populated with the 10 digit number without the dial around 
code, 9192341234. 

6) When the subscriber dials 1-800-228-8288, the Called_Party_Number in SignaHng_Start is populated 
with 8002888288, and the Routing_Number is populated with the translated number after the database 
dip. 
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Table 15: Services supported by On-Net to On-Net call configuration 



Service 


Event Message ID 




1 


2 


3 


4 


5 


6 


7 


8 


9 


10 


11 


12 


13 


14 


15 


16 


17 


19 


20 


21 


22 


Basic 


X 


X 


X 


X 


X 




X 


X 






X 


X 






X 


X 




X 


X 




X 


Call Block 


X 


X 




X 


X 


X 


X 


X 


X 


X 


X 


X 






X 


X 




X 






X 


Call Waiting 


X 


X 




X 


X 


X 


X 


X 


X 


X 


X 


X 






X 


X 




X 






X 


Call Forwarding 


X 


X 




X 


X 


X 


X 


X 


X 


X 


X 


X 






X 


X 




X 






X 


Return Call 


X 


X 




X 


X 


X 


X 


X 






X 


X 






X 


X 




X 






X 


Repeat Call 


X 


X 




X 


X 


X 


X 


X 






X 


X 






X 


X 




X 






X 


Voice Mail 


X 


X 




X 


X 




X 


X 






X 


X 






X 


X 




X 






X 


Three-Way Call 


X 


X 




X 


X 


X 


X 


X 








X 






X 


X 




X 




X 


X 


Customer 
Originated Trace 


X 


X 




X 


X 




X 


X 


X 






X 






X 


X 




X 






X 



Table 16: Services supported by On-Net to Off-Net call configuration 



Service 


Event Message ID 




1 


2 


3 


4 


5 


6 


7 


8 


9 


10 


11 


12 


13 


14 


15 


16 


17 


19 


20 


21 


22 


Basic 


X 


X 


X 


X 


X 




X 


X 






X 


X 


X 


X 


X 


X 




X 


X 




X 


Call Block 


X 


X 




X 


X 


X 


X 


X 


X 


X 


X 


X 


X 


X 


X 


X 




X 






X 


Call Waiting 


X 


X 




X 


X 


X 


X 


X 


X 


X 


X 


X 


X 


X 


X 


X 




X 






X 


Return Call 


X 


X 




X 


X 


X 


X 


X 






X 


X 


X 


X 


X 


X 




X 






X 


Repeat Call 


X 


X 




X 


X 


X 


X 


X 






X 


X 


X 


X 


X 


X 




X 






X 


911 


X 


X 


X 


X 


X 




X 


X 






X 


X 


X 


X 


X 


X 




X 






X 


Nil 


X 


X 


X 


X 


X 




X 


X 






X 


X 


X 


X 


X 


X 




X 






X 


Toil-Free 


X 


X 


X 


X 


X 




X 


X 






X 


X 


X 


X 


X 


X 




X 






X 


Operator 


X 


X 




X 


X 




X 


X 






X 


X 


X 


X 


X 


X 




X 






X 


Three-Way Call 


X 


X 




X 


X 


X 


X 


X 








X 


X 


X 


X 


X 




X 




X 


X 



Table 17: Services supported by Off-Net to On-Net call configuration 



Service 


Event Message ID 




1 


2 


3 


4 


5 


6 


7 


8 


9 


10 


11 


12 


13 


14 


15 


16 


17 


19 


20 


21 


22 


Basic 


X 


X 


X 


X 


X 




X 


X 






X 


X 


X 


X 


X 


X 




X 


X 




X 


Call Block 


X 


X 




X 


X 


X 


X 


X 


X 


X 


X 


X 


X 


X 


X 


X 




X 






X 


Call Waiting 


X 


X 




X 


X 


X 


X 


X 


X 


X 


X 


X 


X 


X 


X 


X 




X 






X 


Repeat Call 


X 


X 




X 


X 


X 


X 


X 






X 


X 


X 


X 


X 


X 




X 






X 


Call Forwarding 


X 


X 




X 


X 


X 


X 


X 


X 


X 


X 


X 






X 


X 




X 






X 


Voice Mail 


X 


X 




X 


X 




X 


X 






X 


X 


X 


X 


X 


X 




X 






X 


Three-Way Call 


X 


X 




X 


X 


X 


X 


X 








X 


X 


X 


X 


X 




X 




X 


X 


Customer Originated 
Trace 


X 


X 




X 


X 




X 


X 


X 






X 


X 


X 


X 


X 




X 






X 



8.1 Event Message Structure 



An Event Message contains a header followed by attributes. The header is required on every Event Message. The 
attributes vary based on the type of service the Event Message is describing. Refer to table 38 for a description of the 
Event Message Header (EM_Header Attribute Structure). 

8.2 Service J nstance 

This event captures the fact that a service event has happened. The Event_Time attribute in the EM_Header Structure 
(see table 38) shall contain the time at which the service occurred. 

This Event Message indicates the time at which the CMS provides an instance of a call control/feature service. For 
example, the time at which a call is put on hold, the time at which a call is forwarded, the time at which a last call return 
service is provided, the time at which a call- waiting service is provided, etc. 
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The CMS shall timestamp these messages immediately upon operation of the service instance being reported. 

The following generic call scenarios and BCIDs are used to specify the call leg for which the CMS sends the 
Servicejnstance Event Message for Call Forwarding, Call Waiting and Three- Way Call Services: 

For Call Forwarding, Subscriber A (BCID-A) calls Subscriber B (BCID-Bl), Subscriber B (BCID-B2) forwards to 
Subscriber C (BCID-C). In this case, the CMS managing Subscriber B shall generate a Servicejnstance Event Message 
with the BCID (BCID-B2) in the EM_Header attribute and the Related_Call_Billing_Correlation_ID attribute shall be 
BCID(BCID-Bl). 

For Call Waiting, Subscriber A (BCID-A) calls Subscriber B (BCID-Bl) and after the call is estabUshed, Subscriber C 
(BCID-C) calls Subscriber B (BCID-B2), who uses call waiting to talk to Subscriber C. In this case, the CMS managing 
Subscriber B shall generate the Servicejnstance Event Message with the BCID (BCID-B2) in the EM_Header attribute 
and the Related_Call_Billing_CorrelationJD attribute shall be BCID (BCID-Bl). 

For Three-Way Call, Subscriber A (BCID-Al) calls Subscriber B (BCID-Bl) and after call is estabUshed, either A or B 
can make Three-Way Call to Subscriber C. When A (BCID-A2) makes Three-Way Call to Subscriber C (BCID-C), the 
CMS managing Subscriber A shall generate the Servicejnstance Event Message with BCID (BCID-A2) in the 
EM_Header attribute and the Related_Call_Billing_CorrelationJD attribute shall be BCID (BCID-Al). When 
Subscriber B (BCID-B2) makes a Three-Way Call to Subscriber C (BCID-C), the CMS managing Subscriber B shall 
generate the Servicejnstance Event Message with BCID(BCID-B2) in the EM_Header attribute and the 
Related_Call_Bining_CorrelationJD attribute shall be BCID (BCID-Bl). 

The following services are part of the IPCablecom EM 1.5 supported service capabilities (see clause 6.2.1): 

• Three_Way_Call. 

• Acct_Auth_Code (Account and Authorization Code Service). 

When a Service_Instance Event Message is generated with a Service_Name of Acct_Auth_Code, at least one of the 
attributes Account_Code or Authorization_Code shall be present, and both may be present. 
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Table 18: Servicejnstance Event Message 



Attribute Name 


Required or 
Optional 


Comment 


EM_Header (see table 38) 


R 


The EM_Header attribute shall be present as the first 
attribute of the EM. 


Service_Name 


R 


The Service_Name attribute shall be present. Class Service 

Name: 

Call_Block 

Call_Forward 

Call_Waiting 

Repeat_Call 

Return_Call 

Three_Way_Call 

Acct Auth Code 


Call_Termination_Cause 





The Call_Termination_Cause attribute shall be present if the 
Service_Name is Call_Block or Acct_Auth_Code. 
If the Service_Name is Acct_Auth_Code, the 
Source_Document field of the Call_Termination_Cause 
attribute shall indicate that the source document is GR- 
1100-CORE - table 235 and the Cause_Code field shall 
include the Call Completion Code as defined in GR-1100- 
CORE - table 235. 


Related Call Billing Correlation 1 
D 





The Related_Call_Billing_Correlation_ID attribute shall be 
present if Service Name is Call Forward, Call Waiting or 
Three_Way_Call. 


Charge_Number 





The Charge_Number attribute shall be present if 
Service_Name is Call_Forward, Call_Waiting, Repeat_Call 
Return Call or Three Way Call. 


First_Call_Calling_Party_Number 





The First_Call_Calling_Party_Number attribute shall be 
present if Service Name is Call Waiting. 


Second_Call_Calling_Party_Numb 
er 





The Second_Call_Calling_Party_Number attribute shall be 
present if Service Name is Call Waiting. 


Called_Party_Number 





The Called_Party_Number attribute shall be present if 
Service Name is Call Waiting. 


Routing_Number 





The Routing_Number attribute shall be present if 
Service Name is Repeat Call or Return Call 


Calling_Party_Number 





The Calling_Party_Number attribute shall be present if 
Service Name is Repeat Call or Return Call. 


Account_Code 





The Account_Code attribute may be present if 
Service Name is Acct Auth Code. 


Authorization_Code 





The Authorization_Code attribute may be present if 
Service Name is Acct Auth Code. 



8.3 



Service Activation 



This event captures a subscriber activating a service. The Event_Time attribute in the EM_Header Structure (see 
table 38) shall contain the time when the service was activated. 

This Event Message indicates the time at which the CMS records an attempt to activate a service. For example, the time 
at which call-forwarding is activated by the MTA user, the time at which the call-waiting service is activated by the 
MTA user, etc. These service activations are typically requested via a. XX dial-string. 

The CMS shall timestamp this message immediately upon successful activation of the requested service. Failed 
activation attempts are not reported at this time. 

The CMS shall create a new BCID for this Event Message even if a service is activated during an existing call. 
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Table 19: Service_Activation Event Message 



Attribute Name 


Required or 
Optional 


Comment 


EM_Header (see Table 38) 


R 


The EM_Header attribute shall be present as the first 
attribute of the EM. 


Service_Name 


R 


The Service_Name attribute shall be present. Class 

Service Name: 

Call_Block 

Call_Forward 

Call_Waiting 

Customer_Originated_Trace 


Calling_Party_Number 


R 


The Calling_Party_Number attribute shall be present if the 
Service_Name is Call_Forward. The 
Calling_Party_Number attribute shall be present if the 
Service_Name is Call_Waiting, Call_Block or 
Customer_Originated_Trace and if the calling party 
number is known. Otherwise, this attribute may be omitted 


Charge_Number 


R 


The Charge_Number attribute shall be present. 


Forwarded_Number 





The Forwarded_Number attribute shall be present if 
Service Name is Call Forward. 



8.4 Signaling_Start 



This Event Message indicates the time at which signalHng starts. It is intended to capture the point at which the NE 
starts processing a call once a routable set of digits have been obtained from the originator. 

The CMS or MGC shall timestamp this message prior to digit translation. Note that the attributes contained in this 
Event Message contain information that is obtained after digit translation. In the event that a database dip is required, 
then the Signaling_Start message shall be generated after the response from the database dip. 

Originating CMS 

In all scenarios, the originating CMS shall timestamp this message immediately upon receipt of an NCS- signalling 
NTFY message with a routable set of digits that indicate a call attempt. 

Terminating CMS 

In the single-zone scenario, the terminating CMS shall timestamp this Event Message based on a vendor-proprietary 
trigger. 

In the intra-domain and inter-domain scenarios, the terminating CMS shall timestamp this Event Message immediately 
upon receipt of an INVITE message with a routable set of dialled digits. 

Originating MGC (off-on) 

The originating MGC shall timestamp this message immediately upon receipt of an SS7 I AM message or a TGCP 
NTFY with digits (operator services). 

Terminating MGC (on-off) 

The terminating MGC shall timestamp this message immediately upon receipt of an INVITE message with a routable 
set of dialled digits. If the MGC is integrated with the CMS, the terminating MGC shall timestamp this message based 
on vendor proprietary trigger. The proprietary trigger may be based on when the lAM is transmitted. The 
Trunk_Group_Number in the Trunk_Group_ID attribute in this message is the trunk group number used to formulate 
the first lAM transmitted to the Signaling Gateway that communicates with PSTN SS7 network for this call. It is 
referenced to the first lAM because potentially due to reattempt handling another lAM may be attempted to complete 
the same call. 
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Table 20: Signaling_Start Event Message 



Attribute Name 


Required or 
Optional 


Comment 


EM_Header (see table 38) 


R 


The ElVI Header attribute shall be present as the first attribute of 
the EM. 


Direction Indicator 


R 


The Direction Indicator attribute shall be present. 


l\/ITA_Endpoint_Name 





If the originating CMS generates this message, 

MTA_Endpoint_Name attribute shall contain the endpoint name of 

the originating MTA. 

If the terminating CMS generates this message, 

MTA_Endpoint_Name attribute shall contain the endpoint name of 

the terminating MTA. 

If the originating MGC generates this message, 

MTA_Endpoint_Name attribute may contain the endpoint ID of the 

originating MG. 

If the terminating MGC generates this message, the 

MTA_Endpoint_Name attribute may contain the endpoint ID of the 

terminating MG. 


Calling_Party_Number 





The Calling_Party_Number attribute shall be included in the 
Signaling_Start Event Message whenever it is available in SS7 or 
CMSS signalling. For example, in the off-net to on-net scenario, 
this attribute may not be present when the Originating MGC and 
Terminating CMS do not have the Calling Party Number attribute 
available from SS7 signalling. 


Called_Party_Number 


R 


The Called_Party_Number attribute shall be present, it holds the 
formatted digits (E.164 [9] format) dialled by the subscriber. Refer 
to clause 8 for examples of how to populate this field. 


Routing_Number 


R 


The Routing_Number attribute shall be present, it indicates a 
routable number 


Location_Routing_Number 





The Location_Routing_Number attribute shall be included if a LNP 
lookup returns a LRN. 


Carrier_ldentification_Code 





The Carrier_ldentification_Code attribute shall be included in MGC 
generated messages in which the call is being routed to an inter- 
exchange carrier and the information is available. 


Trunk_Group_ID 





The Trunk_Group_ID attribute shall be included when the MGC 
generates this message. 


lntl_Code 





The lntl_Code attribute shall be included for call origination of an 
internationally routed call. 


Dial_Around_Code 





The Dial_Around_Code attribute shall be included for call 
origination where the inter-exchange carrier was specified by 
keying in a dial-around code (e.g. 1010288). 


Jurisdiction_lnformation_Par 
ameter 





If the originating MGC generates this messages, the 
Jurisdiction_lnformation_Parameter (JIP) shall be included when 
JIP was received in SS7 message (reference: GR-317-CORE) or if 
the incoming trunk group is provisioned with LRN of remote end. 
If the originating CMS generates this messages, the 
Jurisdiction_lnformation_Parameter shall be included when the 
calling party number is ported-in number. In this case, JIP is per 
CMS provisioning. Note that this may be present even if the calling 
party is not ported in number. If the terminating CMS generates 
this messages, the Jurisdiction_lnformation_Parameter shall be 
included when JIP is received in CMSS interface. 


Called_Party_NP_source 





Number Portability source. The Called_Party_NP_Source 
indicates how CMS or MGC obtained LRN of called party. 


Calling_Party_NP_source 





Number Portability source. The Calling_Party_NP_Source 
indicates how CMS or MGC obtained local number portability 
information for calling party. 


Ported_ln_Calling_Number 





If the originating CMS generates this messages, the 
Ported_ln_Calling_Number attribute shall be included when the 
calling party number is ported-in number. 


Ported_ln_Called_Number 





If the terminating CMS generates this messages, the 
Ported_ln_Called_Number attribute shall be included when the 
called party number is ported-in number. 


Billing_Type 





The Billing_Type attribute shall be included for call origination 
where the originating endpoint is a measured rate subscriber. 
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Attribute Name 


Required or 
Optional 


Comment 


RelatedJCID 





If the CMS or MGC generates this message as a result of 
receiving a SIP INVITE, the RelatedJCID attribute shall contain 
the ICID as received in the P-Charging-Vector SIP 
Header. Otherwise, the CMS or MGC shall populate the 
RelatedJCID attribute based on the ICID created by the CMS or 
MGC and placed in the P-Charging-Vector SIP header of an 
outbound INVITE message. If the ICID is not provided or received, 
this attribute may be omitted. 



8.5 Signaling_Stop 



This Event Message indicates the time at which signalling terminates. It is intended to capture the point at which the NE 
processes the final signalling message for the call. A Signaling_Stop message shall not be generated unless a 
Signaling_Start message with the same BCID has been generated for the call. A Signaling_Stop message shall be 
generated if a Signaling_Start message with the same BCID has been generated for the call (in exception cases, this 
may be the result of a proprietary time-out or clean-up process). 

Originating CMS 

In the single-zone scenario, the originating CMS shall timestamp this EM message immediately upon transmission of 
the NCS-signalling DLCX message. 

In the intra-domain or inter-domain scenarios, the originating CMS shall timestamp this message upon transmission of 
the last signalling event in the following list: 

• transmission of the NCS-signalling DLCX message; or 

• transmission of the CMS S- signalling BYE message or CANCEL message. 

Terminating CMS 

In the single-zone scenario, the terminating CMS shall timestamp this EM message immediately upon transmission of 
the NCS-signalling DLCX message. 

In the intra-domain or inter-domain scenarios, the terminating CMS shall timestamp this message upon transmission of 
the last signalling event in the following list: 

• transmission of the NCS-signalling DLCX message; or 

• transmission of the CMS S- signalling BYE message or the transmission of the CMS S- signalling 
acknowledgment response message to a CANCEL request. 

Originating MGC (off-net to on-net) 

The originating MGC shall timestamp this EM message immediately upon the last signalling event in the following list: 

• transmission/receipt of an RLC to/from the Signaling Gateway that communicates with the SS7 network; 

• transmission of the MGC-issued TGCP DLCX message; 

• receipt of an MG-issued TGCP DLCX; or 

• transmission of the CMS S- signalling BYE message or CANCEL message. 

Terminating MGC (on-net to off-net) 

The terminating MGC shall timestamp this EM message immediately upon transmission of the TGCP-signalling DLCX 
message. 
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Table 21: Signaling_Stop Event Message 



Attribute Name 


Required or 
Optional 


Comment 


EM_Header (see table 38) 


R 


The EM Header attribute shall be present as the first attribute of 
the EM. 


Related_Call_Billing_Correlati 
onJD 





If the originating CMS or MGC generates this message, the 
Related_Call_Billing_Correlation_ID attribute shall contain the 
BCID of the terminating CMS or MGC when terminating CMS or 
MGC is known. If the terminating CMS or MGC is not known, this 
attribute may be omitted. 

If the terminating CMS or MGC generates this message, the 
Related_Call_Billing_Correlation_ID attribute shall contain the 
BCID of the originating CMS or MGC if known. If the BCID of the 
originating CMS or MGC is not known this attribute may be 
omitted. 


FEID 





If the originating CMS or MGC generates this message, the FEID 
attribute shall contain the FEID of the terminating CMS or MGC 
when terminating CMS or MGC is known. If the terminating CMS 
or MGC is not known, this attribute may be omitted. 
If the terminating CMS or MGC generates this message, the FEID 
attribute shall contain the FEID of the originating CMS or MGC. 


Call Termination Cause 


R 


The Call Termination Cause code shall be present. 



8.6 



Service Deactivation 



This Event Message indicates the time at which the CMS records an attempt to deactivate a service. For example, the 
time at which call-forwarding is deactivated by the MTA user, the time at which the call-waiting service is deactivated 
by the MTA user, etc. These service deactivations are typically requested via a. XX dial- string. 

The CMS shall timestamp this message immediately upon successful deactivation of the requested service. Failed 
Deactivation attempts are not reported at this time. 

The CMS shall create a new BCID for this Event Message even if a service is deactivated during an existing call. 

Table 22: Service_Deactivation Event Message 



Attribute Name 


Required or 
Optional 


Comment 


EM_Header (see table 38) 


R 


The EM_Header attribute shall be present as the first 
attribute of the EM. 


Service_Name 


R 


The Service_Name attribute shall be present. Class Service 

Name: 

Call_Block 

Call Forward 

CalLWaiting 


Calling Party Number 


R 


The Calling Party Number attribute shall be present. 


Charge Number 


R 


The Charge Number attribute shall be present. 



Note that in the case of the Call_Waiting Service, the service deactivation or cancellation only applies to the duration of 
one call. If the subscriber has Call_Waiting Service, by default, any call placed or received after the Call_Waiting 
Service deactivation will have call waiting enabled. As a consequence, no Service_ Activation Event Message is 
generated to activate this service again. 



8.7 Database_Query 



This Event Message indicates the time at which a one-time request/response transaction or database dip is completed by 
an intelligent peripheral (800 number database, LNP database, etc.). 

The CMS originating the call shall timestamp this message immediately upon a receipt of the response from the 
Intelligent Peripheral. 
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Table 23: Database_Query Event Message 



Attribute Name 


Required or 
Optional 


Comment 


EM_Header, see (table 38) 


R 


The EM Header attribute shall be present as the first attribute of the 
EM. 


Database ID 


R 


None 


Query_Type 


R 


Toll Free Number Lookup, LNP lookup, etc. 


Called Party Number 


R 


None 


Returned_Number 


R 


NOTE 1 : In the PSTN, only a single number is returned per a 
query for Toll-free/LNP/Calling Name service ([i.9], 
[i.10] and [i.11]). There maybe multiple numbers 
returned such as the 800 translation results in a ported 
number in an optimized response available in AIN 0.2 
([i.7], [i.8]). This is optional for use in TCAP query of 
these services. 

If multiple numbers are returned, this attribute should 
reflect the result associated with the original query as 
indicated in the attribute Query_Type in this message. 
Any additional database dip result should be included 
in the corresponding specific attribute. In the case of 
LNP as a bundled response to the toll free query, the 
Location_Routing_Number should be included to 
convey the additional returned number result from a 
single database query to the SCP. As an alternative, 
the Returned_Number may be included for each 
number returned, but should be included as a pair with 
Query_Type in an ordered sequence. The first pair 
denotes the returned number associated with the 
original query type. The next pair denotes the next 
returned number of the next bundled database dip of 
the same original query. This repeats until the last 
returned number is conveyed. 

NOTE 2: For a calling name database query, this field should 
contain the calling party number provided to the 
database for which the name is being requested. 


Location Routing Number 





See notes above. 


Query_Type 





As a pair with Returned_Number for each of the subsequent 
database dip result within a single original database query. See notes 
in the Returned Number comment column above. 


Returned_Number 





As a pair with Query_Type for each of the subsequent database dip 
result within a single original database query. See notes above. 



8.8 lntelligent_Peripheral_Usage_Start 

Deferred. 

8.9 lntelligent_Peripheral_Usage_Stop 

Deferred. 

8. 1 lnterconnect_Start 

This Event Message indicates the time at which the start of network interconnect occurs. Only the MGC is permitted to 
issue this Event Message. 

The MGC shall timestamp this message immediately upon transmission/receipt of an lAM to/from the Signaling 
Gateway that communicates with the SS7 network. 
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The terminating MGC shall generate this message only after the ACM/ANM is received. This is so that if another lAM 
is attempted due to reattempt handling with a different trunk group number before the ACM/ANM is received, the 
Interconnection_Start reports the latest trunk group number along with the latest timestamp of the final lAM used to 
complete the call. (The Signaling_Start reports the first lAM attempted trunk group number of the same call.) 

The originating MGC may generate this message when the ACM is transmitted although it is timestamp upon receipt of 
an lAM. 

The MGC shall timestamp this message immediately upon transmission/receipt of digits to/from the Media Gateway 
that communicates with the MF/DTMF network. 

The originating MGC shall generate this message only after call answer is transmitted. The Interconnection_Start 
reports the latest trunk group number along with the latest timestamp of answer used to complete the call. (The 
Signaling_Start reports the first attempted trunk group number of the same call.) 

The terminating MGC may generate this message when call answer is received although it is timestamp upon sending 
the digits to the Media Gateway that communicates with the MF/DTMF network. 

Table 24: lnterconnect_Start Event Message 



Attribute Name 


Required or 
Optional 


Comment 


EM_Header (see table 38) 


R 


The EM_Header attribute shall be present as the first 
attribute of the EM. 


Carrier_ldentification_Code 





CIC Code of connecting operator. This attribute shall be 
present when the call is routed off-net to an inter-exchange 
carrier. For example, this attribute can be omitted for 
operator and emergency (911) trunks. 


Trunk_Group_ID 


R 


TGID of the trunk over which the interconnection is 
occurring. 


Routing Number 


R 


None 



8.11 lnterconnect_Stop 



This Event Message indicates the termination of bandwidth between the IPCablecom network and the PSTN. Only the 
MGC is permitted to issue this Event Message. 

The MGC shall timestamp this message immediately upon transmission/receipt of an RLC to/from the Signaling 
Gateway that communicates with the SS7 network. 

The MGC shall timestamp this message immediately upon transmission/receipt of an Release Complete to/from the 
Media Gateway that communicates with the MF/DTMF network. 

Table 25: lnterconnect_Stop Event Message 



Attribute Name 


Required or 
Optional 


Comment 


EM_Header (see table 38) 


R 


The EM_Header attribute shall be present as the first 
attribute of the EM. 


Carrier_ldentification_Code 





CIC Code of connecting operator. This attribute shall be 
present when the call is routed off-net to an inter-exchange 
carrier. For example, this attribute can be omitted for 
operator and emergency (911) trunks. 


Trunk_Group_ID 


R 


TGID of the trunk over which the interconnection is 
occurring. 



8.12 CalLAnswer 

This Event Message indicates that the media connection is open because answer has occurred. It is intended to capture 
the earhest point at which the NE can determine that the termination side has gone off-hook, resulting in a 2-way media 
path. 
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Originating CMS 

In the single-zone scenario, the originating CMS shall timestamp this Event Message based on its knowledge of media 
connection establishment. This trigger should correspond as closely as possible to the time at which the terminating side 
has determined that off-hook has occurred. 

In the multi-zone scenario, the originating CMS shall timestamp this Event Message immediately upon receipt of the 
CMSS signalling 200 OK sent in response to the original INVITE message indicating call answer. 

Terminating CMS 

The terminating CMS shall timestamp this message immediately upon receipt of the NCS-signalling NTFY message 
indicating off-hook at the terminating MTA. 

Originating MGC (off-on) 

The originating MGC shall timestamp this message immediately upon: 

• transmission of an SS7 ANM message to the PSTN via the SO; or 

• commanding the MG to generate answer indication on the operator services trunk. 
Terminating MGC (on-off) 

The terminating MGC shall timestamp this message immediately upon: 

• receipt of an SS7 ANM message from the PSTN via the SG; or 

• an answer indication from the MG indicating answer has occurred on an operator services trunk. 

Table 26: Call_Answer Event Message 



Attribute Name 


Required or 
Optional 


Comment 


EM_Header (see table 38) 


R 


The EM Header attribute shall be present as the first attribute of 
the EM. 


Charge_Number 


R 


The Charge_Number attribute shall contain the charge number in 
the appropriate cases such as collect call, calling-card call, call 
billed to a 3rd party, or others. 


Related_Call_Billing_Correlation_ID 





If the originating CMS or MGC generates this message, the 
Related_Call_Billing_Correlation_ID attribute shall contain the 
BCID of the terminating CMS or MGC when terminating CMS or 
MGC is known. If the terminating CMS or MGC is not known, this 
attribute may be omitted. 

If the terminating CMS or MGC generates this message, the 
Related_Call_Billing_Correlation_ID attribute shall contain the 
BCID of the originating CMS or MGC if known. If the BCID of the 
originating CMS or MGC is not known this attribute may be 
omitted. 


FEID 





If the originating CMS or MGC generates this message, the FEID 
attribute shall contain the FEID of the terminating CMS or MGC 
when terminating CMS or MGC is known. If the terminating CMS 
or MGC is not known, this attribute may be omitted. 
If the terminating CMS or MGC generates this message, the FEID 
attribute shall contain the FEID of the originating CMS or MGC. 
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8.13 CalLDisconnect 

This Event Message indicates the time at which the media connection is closed because the calHng party has terminated 
the call by going on-hook, or that the destination party has gone on-hook and the called-party's call-continuation timer 
has expired. In the current telephony network, when the called party goes on-hook, a 10-1 1 second timer is started. If 
the calling party remains off-hook, and the called party goes off-hook again within that time period, the call continues. 
The call termination cause attribute must be included as an attribute in a CalLDisconnect message; its structure is 
defined in table 41 and its Cause_Code sub-field is normatively defined in [6]. CalLDisconnect should be time-stamped 
by the NE as closely as possible to the time that the media connection is torn down. A CalLDisconnect message shall 
not be generated unless a Call_Answer message with the same BCID has been generated for the call. A 
CalLDisconnect message shall be generated if a Call_Answer message with the same BCID has been generated for the 
call (in exception cases, this may be the result of a proprietary time-out or clean-up process). 

Originating CMS 

The originating CMS shall timestamp this EM message immediately upon transmission of the NCS-signalling DLCX 
message (for calls that have reached the state where the terminating party has gone off-hook and the Call_ Answer 
message was sent). 

Terminating CMS 

The terminating CMS shall timestamp this message immediately upon transmission of the DLCX or upon expiration of 
the terminating MTA's call-continuation timer. 

Originating MGC (off-net to on-net) 

The originating MGC shall timestamp this EM message upon receipt of an SS7 REL message from the PSTN via the 
SG, or upon sending a CMS S- signalling 200-OK message in response to a BYE message from the terminating CMS. 

Terminating MGC (on-net to off-net) 

The terminating MGC shall timestamp this message upon receipt of an SS7 RLC message from the PSTN via the SG, 
an indication from the MG that an operator services trunk has disconnected, or upon sending a 200-OK message in 
response to a BYE message from the originating CMS. 

Table 27: CalLDisconnect Event Message 



Attribute Name 


Required or 
Optional 


Comment 


EM_Header (see table 38) 


R 


The EM_Header attribute shall be present as the 
first attribute of the EM. 


Call Termination Cause 


R 


Normal Termination. 



8.14 QoS_Reserve 

This Event Message indicates the time at which the CMTS reserves bandwidth on the IPCablecom access network. The 
CMTS shall also generate this event if the Reserved bandwidth changes or if the service flow is authorized by another 
gate (through the association of a different Gate than originally authorized the flow). 

The originating and terminating CMTS shall timestamp this message immediately upon: 

Table 28: QoS Reserve Timestamp Generation 



Client initiated 


CMTS initiated 


Client initiated DSA-REQ or DSC-REQ 


CMTS initiated DSA-REQ or DSC-REQ 


reception of a DSA/DSC-ACK acknowledging a successful 
DSA/DSC-RSP (confirmation code == success). 


transmission of a DSA/DSC-ACK acknowledging a 
successful DSA/DSC-RSP (confirmation code == success) 


If a DSA/DSC-ACK is not received, the CMTS shall not 
generate this message. 


If a DSA/DSC-ACK is not transmitted, the CMTS shall not 
generate this message. 
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If the DS A/DSC-RSP confirmation code is not successful, the CMTS shall not generate this message. 

Table 29: QoS_Reserve Event Message 



Attribute Name 


Required or 
Optional 


Comment 


EM_Header (see table 38) 


R 


The EM_Header attribute shall be present as the first 
attribute of the EM. 


QoS Descriptor 





None 


MTA UDP Portnum 


R 


None 


SFID 


R 


None 


Flow Direction 


R 


None 



8.15 QoS Release 



This Event Message indicates the time at which the CMTS released its bandwidth commitment on the IPCablecom 
access network. 

The originating and terminating CMTS shall timestamp this message immediately upon: 

• transmission of a DSC-RSP that indicates that authorization and admission control for a DSC-REQ against an 
existing service flow have succeeded against a separate Gate, indicating that the previous Gate will be deleted; 
or 

• transmission of a DSD-RSP that indicates the request to delete bandwidth contained in the DSD-REQ from the 
MTA was successful; 

• transmission of a DSC-RSP that indicates the request to delete bandwidth contained in the DSC-REQ from the 
MTA was successful. This occurs when the MTA is utilizing multiple grants per interval to place multiple 
sessions on a single service flow and uses a DSC-REQ to delete bandwidth for one of the sessions. 

Table 30: QoS_Release Event Message 



Attribute Name 


Required or 
Optional 


Comment 


EM_Header (see table 38) 


R 


The EM_Header attribute shall be present as the first 
attribute of the EM. 


SF ID 


R 


None 


Flow Direction 


R 


None 



8.16 Time_Change 



This event captures an instance of a time change. Whenever the (IPCablecom) clock on the network element 
(CMS,MGC or CMTS) is changed by more than 200 milliseconds, the network element shall generate a Time Change 
message. This includes time shift events (Daylight savings time), step adjustments to synchronize with the NTP 
reference clock and manual time setting changes. The Event_Time attribute in the EM_Header Structure (table 38) shall 
reflect the new (adjusted) notion of time. Note that Time_Change message is not required for slew adjustments 
performed by NTP. 

The network element (CMS, MGC and CMTS) shall send the Time Change event message to the active (current 
primary) RKS. The Time Change event message shall be generated when one or more calls are active or in the process 
of being set up. For the CMS and MGC active or in process is after a Signaling Start event has been generated. For the 
CMTS active or in process is indicated by the presence of a DQoS gate. The Time Change event message need not be 
generated when calls are not active or in the process of being set up. Only one Time Change event message is sent to 
each primary RKS (if there is more than one primary RKS) regardless of how many calls may be active. 

The BCID in the EM_Header of the Time Change event message shall be generated locally by the network element at 
the time of the event. The BCID is not associated with any call related BCID, it is a unique BCID for this event. 
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Table 31 : Time_Change Event Message 



Attribute Name 


Required or 
Optional 


Comment 


EM_Header (see table 38) 


R 


The EM_Header attribute shall be present as 
the first attribute of the EM. 


Time Adjustment 


R 


None 



8.17 QoS_Comnnit 

This Event Message indicates the time at which the CMTS commits bandwidth on the IPCablecom access network. The 
CMTS shall also generate this event if the Committed bandwidth changes or if the service flow is authorized by another 
gate (through the association of a different Gate than originally authorized the flow). 

The originating and terminating CMTS shall timestamp this message immediately upon: 

Table 32: QoS Commit Timestamp Generation 



Client initiated 


CMTS initiated 


Client initiated DSC-REQ or a DSA-REQ (when the CMTS 
reserves and commits the bandwidth in one-step). 


CMTS initiated DSC-REQ or a DSA-REQ (when the CMTS 
reserves and commits the bandwidth in one-step). 


reception of a DSA/DSC-ACK acknowledging a successful 
DSA-RSP/DSC-RSP (confirmation code == success). 


transmission of a DSA/DSC-ACK acknowledging a 
successful DSA/DSC-RSP (confirmation code == 
success). 


If a DSA/DSC-ACK is not received, the CMTS shall not 
generate this message. 


If a DSC-ACK is not transmitted, the CMTS shall not 
generate this message. 



If the DSA/DSC-RSP confirmation code is not successful, the CMTS shall not generate this message. 

Table 33: QoS_Commit Event Message 



Attribute Name 


Required or 
Optional 


Comment 


EM_Header (see table 38) 


R 


The EM_Header attribute shall be present as 
the first attribute of the EM. 


QoS Descriptor 





None 


MTA UDP Portnum 


R 


None 


SF ID 


R 


None 


Flow Direction 


R 


None 



8.18 RTP_Connection_Parameters Event Message 

Deferred. 

8.19 Media_Alive 

If the IPCablecom architecture is expected to support this Media_Alive Event Message, then it is recommended that all 
CMS, CMTS, and MGC be pre-configured with the same Media_Alive generation time. 

This Event Message indicates that service is active due to the continued existence of a bearer connection. This Event 
Message may be generated by any trusted IPCablecom network element (CMS, CMTS, MGC) as defined below. 

If a NE is configured to generate the optional Media_Alive event message, it must check for the status of all calls at the 
configured Media_Alive generation time. At the configured Media_Alive generation time, (e.g. 00:00 means midnight, 
23:59 means 1 1:59 PM) the NE checks if any of the active calls are equal to or older than 1 440 minutes. (24 hours). 
Only if a call is equal to or older than 1 440 minutes, a Media_Alive event message for that call shall be generated. 
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The call starting time for different NE types are specified by: 

• CMTS: the first QoS_Commit event message EM_Header attribute Event_time for a gate. 

• CMS: the Call_Answer event message EM_Header attribute Event_time. The EM_Header attribute 
Event_time is time stamped as per clause 8.12 Call_Answer. 

• MGC: the Call_Answer event message EM_Header attribute Event_time. The EM_Header attribute 
Event_time is time stamped as per clause 8.12 Call_Answer. 

NEs shall (when configured to generate the Media_Alive EMs) generate the Media_Alive EMs at the Media_Alive EM 
generation time. Even though the Media_ Alive EM generation time is configurable, the default value for the 
Media_Alive EM generation time shall be midnight. Thus a service provider can have a synchronized network simply 
by accepting the default value from all NEs. If a service provider wants different time for Media_Alive EM generation 
time, it is up to the service provider to configure the different Media_Alive EM generation time. 

The following diagram illustrates how a long duration call is identified. 

Assumption: the Media_Alive EM generation on the NE has been configured to midnight (00:00) (the default value). 

Call A is not a long duration call because its duration is less than 24 hours (or 1 440 minutes) long. 

Call B is not a long duration call because its duration is longer than 24 hours but it is less than 1 440 minutes long at the 
Media_Alive EM generation time (midnight). 

Call C is a long duration call because at the second midnight after the call was established, its duration is longer than 
1 440 minutes, (actually 2 340 minutes long). Only one Media_Alive is generated because it is terminated prior to the 
next Media_ Alive EM generation time (midnight). 

Call D is also a long duration call because it meets the same criterion as Call C. Because it stays up across the midnight 
boundary after becoming a long duration call, two Media_Alive EMs are generated. 



midnight 



midnight 



midnight 



midnight 



midnight 



Call A: 

duration < 24 hours. 
Not a long duration ca 



CallB: 

duration > 24 hours. 
Not a long duration ca 



Call C: 

A long duration call. 



Call D: 

A long duration call. 



T Call_j)i 



Call_Answer 



Call Answer 



Call_Answer 



Call_Answer 



Call_Disconi}ect 



Media_Alive 



Call_Disconnect 



Media_Alive J 



Media_Alive | Media_Alive 



Cal]i_Disconnect 
t3 



Figure 5: Long Duration Call Identification 

From the above diagram. Call D will be used to illustrate the contents of the long duration call records belonging to a 
same call id (BCID). 

In above scenario, there will be three records generated from Call D, let's identify these as record 1, 2, and 3. 

The Call D starts on day at 9:00:00 AM. (tO July 27, 2001). 
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At first midnight crossing, the call is 900 minutes long (or 5 400 seconds). So no record is generated. 

At second midnight crossing (tl), the call is 2 340 minutes long (or 140 400 seconds). So a Media_Alive Event 
Message is generated with the following value: 

EM Header.Event_time = 20010729000000.000 

At third midnight crossing (t2), the call is 3 780 minutes long (or 22 6800 seconds). A Media_Alive event message with 
the following value is generated: 

EM Header.Event_time = 20010730000000.000 

At 5:00pm, following the third midnight, the call is terminated. (t3). The overall duration of the call is 4 800 minutes 
long (or 288 000 seconds). A Call_Disconnect event message with the following value is generated for this call BCID. 

EM Header.Event_time = 20010730170000.000 

Table 34: Media_Alive Event Message 



Attribute Name 


Required or 
Optional 


Comment 


EM_Header, see (table 38) 


R 


The EM_Header attribute shall be present as the 
first attribute of the EM. 



8.20 Media_Statistics 

This Event Message is generated when a gateway returns VoIP Metrics in NCS or TGCP messages. 

CMSs and MGCs may generate and time-stamp this message when an NCS or TGCP signalling message is received 
from the MTA/MG that contains VoIP Metrics data. If this optional Event Message is generated, it shall contain all of 
the VoIP metrics data received as specified in table 35. VoIP metrics data is defined as that contained within the Local 
and Remote XR_B locks, RTCP data is not considered VoIP metrics data even though it is contained in this message. 
See Error! Reference source not found, for more information on how this data is represented in NCS signalling, and to 
determine which NCS messages may carry this data. CMSs and MGCs shall not generate this message when no VoIP 
Metrics data is received in the NCS or TGCP signalling messages. 

Within the NCS or TGCP Signaling response from the MTA/MG, the RTCP_Data metrics are found in the P: 
parameter, the Local_XR_Block metrics are found in the XRM/LVM: parameter, and the Remote_XR_Block metrics 
are found in the XRM/RVM parameter. The CMS and MGC shall remove the parameter name, and copy the metrics as 
they appear in NCS or TGCP into the appropriate Media_Statistics attribute. 

Note that in a very common case, VoIP Metrics data is included in the response to a DLCX message. In this case, the 
time-stamp is later than the Signaling_Stop message. Thus, it is not valid to assume that the Signaling_Stop message is 
necessarily the last message associated with a voice connection. 

Table 35: Media_Statistics Event Message 



Attribute Name 


Required or 
Optional 


Comment 


EM_Header (see table 38) 


R 


The EM Header attribute shall be present as the first attribute of the 
EM. 


RTCP_Data 





The RTCP_Data attribute shall be present if an NCS or TGCP 
message was received with any RTCP report data included. 


Local_XR_Block 





The _XR_Block shall be present if an NCS or TGCP message was 
received with any local VoIP metrics data included. 


Remote_XR_Block 





The Remote_XR_Block shall be present if an NCS or TGCP message 
was received with any remote VoIP metrics data included. 
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9 



IPCablecom event message attributes 



This clause describes the IPCablecom attributes included in the IPCablecom Event Messages. Event Messages and 
attributes denoted by an asterisk "*" in table 36 indicate that the message or attribute is specific to electronic 
surveillance Event Messages. Electronic surveillance specific Event Messages and/or attributes shall not be sent to the 
RKS. 

Table 36 shows a mapping of the IPCablecom Event Messages and their associated IPCablecom attributes, table 37 
contains a detailed description of the IPCablecom attributes. 

Table 36: IPCablecom Attributes Mapped to IPCablecom Event Messages 



EM 

Attribute 

ID 


EM Attribute 
Name 


Event Message ID 






r 
S 

"^ 

c 

1 

(J) 

1- 


a. 

i 

£ 

75 

c 

(J) 

CM 


f 

Q 

CO 


1 

0) 
Q 


Q 


s 

c 
c 

E 


t 

(0 

1 
1- 


(f) 

8 

00 


c 
_o 

c5 

> 

o 

o 

> 

O) 


c 
_o 

c3 

> 

o 
re 

E 

O 

1- 


.5 


o 

c 
re 
w 

c 

1 
re 

c 

(J) 

CM 


1 

c 
o 
o 

B 

c 

CO 

1- 


a. 
o 

o 

c 
o 
o 

1 


1 

(0 

c 

^1 

re 
O 

in 


S 

c 
c 
o 

re 
O 

to 


c 
re 

1 


.■= 
E 
E 
o 

:^' 

o 
O 

CJ) 


5 


c 

"^ 

5 
s 

£ 
o 

9 

CM 


1 

1 

?5l 


o 

5 
1 
1 

CO 
CM 


c 
o 





Reserved 
















































1 


EM_Header 


X 


X 


X 






X 


X 


X 


X 


X 


X* 


X* 


X 


X 


X 


X 


X 


X 


X 


X* 


X 


X* 


X* 


2 


Undefined 
















































3 


MTA_Endpoint_N 
ame 


X 














































4 


Calling_Party_Nu 
mber 


X 










X 






X 


X 




























5 


Called_Party_Nu 
mber 


X 




X 






X 




































6 


Database_ID 






X 










































7 


Query_Type 






X 










































8 


Undefined 
















































9 


Returned_Number 






X 










































10 


Undefined 
















































11 


Call_Termination_ 
Cause 




X 








X 




















X 
















12 


Undefined 
















































13 


Related_Call_Billi 

ng_ 

CorrelationJD 




X 








X 


















X 
















X* 


14 


First_Call_Calling 
Party_Number 












X 




































15 


Second_Call_ 

Calling_Party_Nu 

mber 












X 




































16 


Charge_Number 












X 






X 


X 










X 


















17 


Forwarded_Numb 
er 


















X 






























18 


Service_Name 












X 






X 


X 




























19 


Undefined 
















































20 


IntLCode 


X 














































21 


Dial_Around_Cod 
e 


X 















































ETSI 



48 



ETSI TS 1 03 1 61 -6 V1 .1 .1 (201 1 -04) 



EM 

Attribute 

ID 


EM Attribute 
Name 


Event Message ID 






£ 

75 

c 

(J) 


Q. 

o 

c 

75 

c 

CM 


f 

CO 


a> 

1 

Q 


0) 
0) 

Q 


a> 
o 

c 

(0 

w 

c 

i' 

1 


> 

a> 

1 


SI 

(0 

1 

00 


1 

o 

: 

o 

> 

O) 


c 
o 

> 
o 

(0 

5 

o 

1 

o 


r 

a 

i 


8 

c 

c 
_l 
re 

c 

CM 


r 

! 

o 

c 
o 
o 

1 

CO 


Q. 

o 

5 

c 
c 

8 
1 


i 

c 

<, 

S 


1 

i 


re 


1 

I 

o 
o 

CJ) 


're' 


a> 

O) 

c 
re 

c 
o 

9 

CM 


(0 

re' 

CM 
CM 


O 

a> 
o 

c 
re 

1 

g3 


c 
_o 

o 

1 
cc 


22 


Location_Routing 
_ Number 


X 




X 










































23 


Carrierjdentificati 
on_ Code 


X 










X* 














X 


X 


















X* 


24 


Trunk_Group_ID 


X 
























X 


X 




















25 


Routing_Number 


X 










X 














X 






















26 


MTA_UDP_Portnu 
m 














X 






















X 












27 


Undefined 
















































28 


Undefined 
















































29 


Channel_State 






















X* 


























30 


SFJD 














X 


X 




















X 












31 


Error_Description 
















































32 


QoS_Descriptor 














X 






















X 












33 


Undefined 
















































34 


Undefined 
















































35 


Undefined 
















































36 


Undefined 
















































37 


Directionjndicator 


X 














































38 


Time_Adjustment 


































X 














39 


SDP_Upstream 






















X* 


























40 


SDP_Downstream 






















X* 


























41 


Userjnput 


X* 














































42 


Translationjnput 


X* 














































43 


Redirected From 
Inf 


X* 














































44 


Electronic_Surveill 
ance_ Indication 


X* 










































X* 




45 


Redirected_From_ 
Party_Number 












X* 


































X* 


46 


Redirected_To_P 
arty_ Number 












X* 


































X* 


47 


Undefined 
















































48 


CCCJD 














X* 


X* 






X* 














X* 












49 


FEID 




X 


























X 


















50 


Flow_Direction 














X 


X 






X* 














X 













ETSI 



49 



ETSI TS 1 03 1 61 -6 V1 .1 .1 (201 1 -04) 



EM 

Attribute 

ID 


EM Attribute 
Name 


Event Message ID 






£ 

75 

c 

(J) 


Q. 

o 

c 

75 

c 

CM 


f 

CO 


a> 

1 

Q 


0) 
0) 

Q 


a> 
o 

c 

(0 

w 

c 

i' 

1 


> 

a> 

1 


Si 

(0 

1 

00 


§ 
1 

o 

: 

o 

> 

O) 


c 
o 

> 
o 

(0 

5 

o 

1 

o 


r 

a 

1 


S 

c 

c 
_l 
re 

c 

CM 


r 

! 

o 

c 
o 
o 

1 

CO 


Q. 

o 

5 

c 
c 

8 
1 


1 

c 


1 
1 


re 


E 

I 

o 
O 

CJ) 




a> 

O) 

c 
re 

c 
o 

9 

CM 


(0 

re' 

CM 
CM 


o 

a> 
o 

c 
re 

1 

g3 


c 
_o 

o 
a> 

1 

DC 


51 


Signal_Type 
























X* 
























52 


Alerting_Signal 
























X* 
























53 


Subject_Audible_ 
Signal 
























X* 
























54 


Terminal Display 
Info 
























X* 
























55 


Switch Hook Flas 
h 
























X* 
























56 


Dialed_Digits 
























X* 
























57 


Misc_Signaling_ln 
formation 
























X* 
























61-79 


Reserved 
















































80 


Account_Code 












X 




































81 


Authorization_Cod 
e 












X 




































82 


Jurisdictionjnfor 
mation_Parameter 


X 














































83 


Called_Party_NP_ 
Source 


X 














































84 


Calling_Party_NP 
_Source 


X 














































85 


Ported_ln_Calling 
_Number 


X 














































86 


Ported_ln_Called_ 
Number 


X 














































87 


Billing_Type 


X 














































88 


Signaled_To_Num 
ber 
























X* 
























89 


Signaled_From_N 
umber 
























X* 
























90 


Communicating_P 
arty 








































X* 








91 


Joined_party 








































X* 








92 


Removed_Party 








































X* 








93 


RTCP_Data 










































X 






94 


Local_XR_Block 










































X 






95 


Remote XR Bloc 
k 










































X 






96 


Surveillance_Stop 
Type* 












































X* 




97 


Surveillance_Stop 
Destination* 












































X* 




98 


RelatedJCID 


X 















































ETSI 



50 



ETSI TS 1 03 1 61 -6 V1 .1 .1 (201 1 -04) 



Table 37 provides a detailed list of the IPCablecom Event Message attributes. A data value of an attribute may be 
represented by a simple data format (one data field) or by a more complex data format (Data Structure). Data Structure 
formats of the appropriate attributes are detailed in table 38 through table 44. It should be noted that Event Message 17 
is not service dependent. 

Table 37: IPCablecom Event Message Attributes 



EM 

Attribute 

ID 


EM Attribute 
Length 


EM Attribute Name 


EM Attribute 
Value Type 


Attribute Data Description 





Reserved 


1 


76 bytes 


EI\/l_Header 


Data structure (See 
table 38) 


Common data required on every 
IPCablecom Event Message 


2 


Undefined 


3 


variable length, 
maximum of 247 
bytes (247 is 
maximum length of 
vendor specific 
attribute) 


l\/ITA_Endpoint_Name 


ASCII character 
string 


Physical Port name (aaln/#) as defined 
in the IPCablecom NCS Spec [1]. 


4 


20 bytes 


Calling_Party_ Number 


Right justified, 
space padded 
ASCII character 
string 


IPCablecom 1.5 will use E.I 64 [9] 
formatted address specifying the 
number of the Originating party. In the 
future other numbering plans will be 
addressed. 


5 


20 bytes 


Called_Party_ Number 


Right justified, 
space padded 
ASCII character 
string 


IPCablecom 1 .5 will use E.I 64 [9] 
formatted address specifying the 
number of the terminating party. In the 
future other numbering plans will be 
addressed. 


6 


Variable length, 
maximum of 247 
bytes (247 is 
maximum length of 
vendor specific 
attribute) 


Database_ID 


Right justified, 
space padded 
ASCII character 
string 


A unique identifier of the referenced 
database 


7 


2 bytes 


Query_Type 


Unsigned integer 


Query type: 

0=Reserved 

1=Toll Free Number Lookup 

2=LNPNumberLookup 

3=Calling Name Delivery Lookup 


8 


Undefined 


9 


20 bytes 


Returned_Number 


Right justified, 
space padded 
ASCII character 
string 


IPCablecom 1 .5 will use E.I 64 [9] 
formatted address specifying the 
number resulting from a database 
query. In the future other numbering 
plans will be addressed. 


10 


Undefined 


11 


6 bytes 


Call_Termination_Cause 


Data structure (See 
table 41) 


Termination code identifier 


12 


Undefined 


13 


24 bytes 


Related_Call_ Billing_ 
CorrelationJD 


Data structure. (See 
table 39) 


BCID for possible use in value added 
services or to identify the matching 
originating/terminating half of the 
service. 


14 


20 bytes 


First_Call_Calling_Party_Number 


Right justified, 
space padded 
ASCII character 
string 


IPCablecom 1 .5 will use E.I 64 [9] 
formatted address specifying the 
number of the calling party. In the 
future other numbering plans will be 
addressed. 


15 


20 bytes 


Second_Call_ Calling_Party_ 
Number 


Right justified, 
space padded 
ASCII character 
string 


IPCablecom 1 .5 will use E.I 64 [9] 
formatted address specifying the 
number of the calling party. In the 
future other numbering plans will be 
addressed. 


16 


20 bytes 


Charge_Number 


Right justified, 
space padded 
ASCII character 
string 


IPCablecom 1.5 will use E.I 64 [9] 
formatted address specifying the 
number of the billable party. In the 
future other numbering plans will be 
addressed. 
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EM 

Attribute 

ID 


EM Attribute 
Length 


EM Attribute Name 


EM Attribute 
Value Type 


Attribute Data Description 


17 


20 Bytes 


Forwarded_ Number 


Right justified, 
space padded 
ASCII character 
string 


IPCablecom 1 .5 will use E.I 64 [9] 
formatted address specifying the 
number of the Forwarded Number. In 
the future other numbering plans will 
be addressed. 


18 


32 Bytes 


Service_Name 


Right justified, 
space padded 
ASCII character 
string 


Class Service Name. Allowed names 

are: 

Call_Block 

Call_Forward 

Call_Waiting 

Repeat_Call 

Return Call 

Three_Way_Call 

Customer_Originated_Trace 


19 


Undefined- 


20 


4 Bytes 


IntLCode 


Right justified, 
space padded 
ASCII character 
string 


International Country Code 


21 


8 Bytes 


Dial_Around_Code 


Right justified, 
space padded 
ASCII character 
string 


Dial-around code used for per-call 
selection of inter-exchange carrier 


22 


20 bytes 


Location_Routing_Number 


Right justified, 
space padded 
ASCII character 
string 


For LNP uses IPCablecom 1.5 will use 
E.I 64 [9] formatted address specifying 
the number of the terminating party. In 
the future other numbering plans will 
be addressed. 


23 


8 bytes 


Carrier_ ldentification_ Code 


Right justified, 
space padded 
ASCII character 
string 


If the cable operator provides a 
service for a telecommunications 
operator, the Carrier Identification 
Code (CIC) or other identification is 
recorded in this field. 


24 


6 bytes 


Trunk_Group_ID 


Data structure (See 
table 42) 


Trunk group identification 


25 


20 bytes 


Routing_Number 


Right justified, 
space padded 
ASCII character 
string 


IPCablecom 1 .5 will use E.I 64 [9] 
formatted address specifying the 
number of the terminating party. In the 
future other numbering plans will be 
addressed. 


26 


4 bytes 


MTA_UDP_Portnum 


Unsigned Integer 


MTA Endpoint UDP Port Number. 
Destination port field value in DQoS 
Gate-spec object received in DQoS 
Gate-Set message. 


27 


Undefined 


28 


Undefined 


29 


2 bytes 


ChanneLState 


Unsigned 
Integer 


Channel State: 
0=Not Used/Reserved 

1=0pen 

2=Change 

3=Close 


30 


4 bytes 


SFJD 


Unsigned integer 


Service Flow ID, a 32-bit integer 
assigned by the CMTS to each 
DOCSIS Service Flow defined within a 
DOCSIS RFMAC domain. SFIDs are 
considered to be in either the 
upstream direction (USFID) or 
downstream direction (DSFID). 
USFIDs and DSFIDs are allocated 
from the same SFID number space. 


31 


32 bytes 


Error_Description 


Right justified, 
space padded 
ASCII character 
string. 


A user-defined description of the error 
conditions. (See table 40) 


32 


Variable; Min 8 
bytes 


QoS_Descriptor 


Data structure 
See table 43. 


QoS parameters data 
(See Appendix C of [i. 3]) 
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EM 

Attribute 

ID 


EM Attribute 
Length 


EM Attribute Name 


EM Attribute 
Value Type 


Attribute Data Description 


37 


2 bytes 


Direction_ 
indicator 


Unsigned integer 


Specifies if a device acts on behalf of 

an originating or terminating part of the 

call at the time an Event Message is 

being generated. 

0=undefined 

1=0riginating 

2=Terminating 


38 


8 bytes 


Time_Adjustment 


signed integer 


Time adjustment of an element's 
(CMS, CMTS, MGC) clock. 
This time is in milliseconds, detailing 
the amount of the time change. 


39 


variable 


SDP_Upstream 


ASCII character 
string 


Description of upstream packet flow 


40 


variable 


SDP_Downstream 


ASCII character 
string 


Description of downstream packet flow 


41 


variable 


Userjnput 


ASCII character 
string 


Sequence of dialed digits as entered 
by user 


42 


20 bytes 


Translationjnput 


Right justified, 
space padded 
ASCII character 
string 


E.I 64 [9] address of the input to an 
external translation lookup 


43 


42 bytes 


Redirected_From_lnfo 


Data Structure 


Information about previous 
redirections of this call 


44 


variable 


Electronic_ Surveillance_ Indication 


Data Structure 


Additional destination of CCC and 
CDC for redirected call 


45 


20 bytes 


Redirected_From_Party_Number 


Right justified, 
space padded 
ASCII character 
string 


E.I 64 [9] address of the party initiating 
a redirection 


46 


20 bytes 


Redirected_To_ Party_Number 


Right justified, 
space padded 
ASCII character 
string 


E.I 64 [9] address of the destination 
party of a redirection 


47 


Undefined 


48 


4 bytes 


CCCJD 


Unsigned integer 


Call Content identifier assigned by 
CMS or MGC 


49 


Variable length, 
maximum of 247 
bytes 


FEID 


ASCII character 
string. 


Financial Entity ID. The first 8 bytes 
constitute cable operator defined data. 
By default, the first 8 bytes are zero 
filled. From the 9th byte on the field 
contains the cable operator's domain 
name which uniquely identifies the 
cable operator for billing and 
settlement purposes. The cable 
operator's domain name is limited to 
239 bytes. 


50 


2 bytes 


Flow Direction 


Unsigned integer 


Flow direction: 
0=Reserved 
1=Upstream 
2=Downstream 


51 


2 bytes 


Signal_Type 


Unsigned Integer 


Type of signal: 

= Reserved 

1 = Network_Signal 

2 = Subject Signal 


52 


4 bytes 


Alerting_Signal 


Unsigned Integer 


Type of alerting signal (NOTE 1): 

= Reserved 

1 = Ringing (rg) 

2 = Distinctive ringing 2 (r2) 

3 = Distinctive ringing 3 (r3) 

4 = Distinctive ringing 4 (r4) 

5 = Ringsplash (rs) 

6 = Call waiting tone 1 (wtl) 

7 = Call waiting tone 2 (wt2) 

8 = Call waiting tone 3 (wt3) 

9 = Call waiting tone 4 (wt4) 

1 = Reserved 

1 1 = Distinctive ringing (rO) 

12 = Distinctive ringing 1 (r1) 

13 = Distinctive ringing 5 (r5) 

14 = Distinctive ringing 6 (r6) 

15 = Distinctive ringing 7 (r7) 
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EM 

Attribute 

ID 


EM Attribute 
Length 


EM Attribute Name 


EM Attribute 
Value Type 


Attribute Data Description 


53 


4 bytes 


Subject_Audible_Signal 


Unsigned Integer 


Type of audible signal (NOTE 2): 

= Reserved 

1 = Dial tone (dl) 

2 = Stutter dial tone (si) 

3 = Ring back tone (rt) 

4 = Reorder tone (ro) 

5 = Busy tone (bz) 

6 = Confirmation tone (cf) 

7 = Reserved 

8 = Message waiting indicator (mwi) 

9 = Off-hook warning tone (ot) 

1 = Reserved 

1 1 = Reserved 

1 2 = Reserved 

1 3 = Reserved 

1 4 = Reserved 

1 5 = Reserved 

1 6 = Reserved 

1 7 = Reserved 

1 8 = Reserved 

1 9 = Reserved 

20 = Reserved 

21 = Reserved 


54 


Variable length, 
maximum of 201 
bytes 


Terminal_Display_lnfo 


Data Structure (see 
table A.1 1) 


Provides information signalled for 
display on surveillance subject's 
terminal. 


55 


Variable length, 
maximum of 128 
bytes 


Switch_Hook_Flash 


ASCII character 
string 


Indicates signalling of a flash hook. 

Value is "FLASHHOOK" for Flash 
hook signal (hf). 


56 


Variable length, 
maximum of 128 
bytes 


Dialed_Digits 


ASCII character 
String 


Provides digits dialed. 

Value is digits received for DTMF 

digits signal (0-9,*,#,A,B,C,D). 


57 


Variable length, 
maximum of 128 
bytes 


Misc_Signaling_lnformation 


ASCII character 
string 


Provides miscellaneous signalling 

information. 

Attribute is populated as follows: 

- Value is digits sent for DTMF digits 
signal (0-9,*,#,A,B,C,D). 

- Value is "FAX TONE" for Fax tone 
signal (ft). 

- Value is "MODEM TONE" for Modem 
tone signal (mt). 

- Value is "TDD TONE" for TDD signal 
(TDD). 


61-79 








Reserved for IPCablecom Multimedia 


80 


24 bytes 


Account_Code 


Right justified, 
space padded 
ASCII character 
string 


Account code used for this call. 


81 


24 bytes 


Authorization 
Code 


Right justified, 
space padded 
ASCII character 
string 


Authorization code used for this call; it 
may be used to segment an account 
code. 


82 


6 bytes 


Jurisdiction_lnformation_Parameter 


Right justified, 
space padded 
ASCII character 
string 


The originating network element's JIP 
asperGR-317-CORE. 


83 


2 bytes 


Called_Party_NP_Source 


Unsigned integer 


Provisioned data 
Signaling Information 
NPDB 


84 


2 bytes 


Calling_Party_NP_Source 


Unsigned integer 


Provisioned data 
Signaling Information 
NPDB 


85 


2 bytes 


Ported_ln_Calling_Number 


Unsigned integer 


Value: 

0= Not ported In 

1= ported In 


86 


2 bytes 


Ported_ln_Called_Number 


Unsigned integer 


Value: 

0= Not ported In 

1= ported In 
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EM 

Attribute 

ID 


EM Attribute 
Length 


EM Attribute Name 


EM Attribute 
Value Type 


Attribute Data Description 


87 


2 bytes 


Billing_Type 


Unsigned integer 


Indicates if the call is measured rate or 
flat rate. Value: 

1 = Measured rate (aligned with BAF 
call type 1 that indicates a local 
message rate call or a measured call) 
3 = Flat rate (aligned with BAF call 
type 3 that indicates local message 
rate that is not timed) 


88 


20 bytes 


Signaled_To_Number 


Right justified, 
space padded 
ASCII character 
string 


IPCablecom 1 .5 will use E.164 [9] 
formatted address specifying the 
number of the Originating party. In the 
future other numbering plans will be 
addressed. 


89 


20 bytes 


Signaled_From_Number 


Right justified, 
space padded 
ASCII character 
string 


IPCablecom 1 .5 will use E.164 [9] 
formatted address specifying the 
number of the Originating party. In the 
future other numbering plans will be 
addressed. 


90 


26 bytes 


Communicating_Party 


Data Structure (see 
table 47) 


CCCJDand Party ID of the 
communicating party in the 
conference. 


91 


26 bytes 


Joined_Party 


Data Structure (see 
table 47) 


CCCJD and Party ID of the party that 
joined the conference. 


92 


26 bytes 


Removed_Party 


Data Structure (see 
table 47 


CCCJD and Party ID of the party 
removed from the conference. 


93 


variable 


RTCP_Data 


ASCII character 
string 


RTCP metrics available on a 
connection. 


94 


variable 


Local_XR_Block 


ASCII character 
string 


Local RTCP-XR VoIP Metrics Block 
data available on a connection. 


95 


variable 


Remote_XR_Block 


ASCII character 
string 


Remote RTCP-XR VoIP Metrics Block 
data available on a connection. 


96 


2 bytes 


Surveillance_Stop_Type 


Unsigned Integer 


Value: 

= Reserved 

1 = End of surveillance (CDC and, if 
present, CCC) 

2 = End of CCC only (CDC will 
continue) 


97 


2 bytes 


Surveillance_Stop_Desti nation 


Unsigned Integer 


Value: 

= Reserved 

1 = Surveillance_Stop applies to local 
surveillance only 

2 = Surveillance_Stop applies to both 
local and remote surveillance 

3 = Surveillance_Stop applies only to 
remote surveillance 


98 


variable 


RelatedJCID 


ASCII character 
string 


IMS Charging Identifier (ICID) is used 
to allow correlation of Event Messages 
generated by CMSes and MGCs with 
Accounting Events generated by other 
network elements [7]. 


NOTE 1 : The values are the standard values defined for a circuit-switched environment to report alerting signals for 
voice services to law enforcement. The "Reserved" values are for alerting signals that are not relevant to an 
IPCablecom environment, and have been reserved to achieve consistent reporting across different voice 
environments. 

NOTE 2: The values are the standard values defined for a circuit-switched environment to report alerting signals for 
voice services to law enforcement. The "Reserved" values are for alerting signals that are not relevant to an 
IPCablecom environment, and have been reserved to achieve consistent reporting across different voice 
environments. 



9.1 



EM Header Attribute Structure 



Table 38 contains a detailed description of the fields in the EM_Header attribute structure. This Event Message Header 
attribute shall be the first attribute in every IPCablecom Event Message. 
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Table 38: EM Header Attribute Structure 



Field Name 


Semantics 


Value Type 


Length 


VersionJD 


Identifies version of this structure. 

1 = IPCablecom 1.0 

2 = IPCablecom 1.1 

3 = IPCablecom Multimedia 

4 = IPCablecom 1.5 

The CMS, MGC and CMTS network element shall set the 

value of the VersionJD to 4. 

NOTE 1 : A value of >= 2 indicates the Event_Object field in 

this header is used. 
NOTE 2: Note that IPCablecom 1.1 was an interim 

IPCablecom release that has now been 

subsumed by IPCablecom 1 .5. This value was left 

to aid in release transitioning. 


Unsigned integer 


2 bytes 


BCID 


Unique identifier for a transaction within a network. See 
following clause. 


Data Structure 
(See table 39) 


24 bytes 


Event_Message_Type 


Identifies the type of Event Message. 

Refer to table 14 for a listing of Event message types. 


Unsigned integer 


2 bytes 


Element_Type 


Identifies Type of Originating Element: 

= Reserved 

1 =CMS 

2 = CMTS 

3 = Media Gateway Controller 


Unsigned integer 


2 bytes 


ElementJD 


Network wide unique identifier 

5 digits (statically configured element number unique within 
an IPCablecom domain in the range of 0-99,999) 


Right justified, space 
padded ASCII 
Character String 


8 bytes 


Time_Zone 


Identifies daylight savings time and offset from universal 

time (UTC). 

Daylight Savings Time: 

= Standard Time 

1 = Daylight Savings 

The Daylight-Savings Time indicator shall be set to a value 
of 1 if the network element is in a region that implements 
DST and then only during the daylight-saving-time period 
(usually the summer months). Since there may be areas in 
which the daylight-saving-time offset indicates a time- 
change other than 1 hour, the receiving system (e.g. RKS) 
needs to correctly calculate local time based on knowledge 
of the area(s) in which the subscriber and the network 
element reside. 
UTC offset: ± HHMMSS 
The offset is reported from the network element 
(CMS/MGC/CMTS) point of view; not based on the 
subscriber point of view. 

The UTC offset represents the time offset from universal 
time (formerly called Greenwich Mean Time, or GMT) when 
standard time is in effect and shall not change on transition 
into or out of daylight-saving-time. 
For example: the Time_Zone field of a network element in 
Boston in December is "0-050000". The same network 
element in Boston in July is "1-050000". 


ASCII character 
string 


1 byte 
7 bytes 


Sequence_Number 


Each network element shall assign a unique and 
monotonically increasing unsigned integer for each Event 
Message sent to a given RKS pair (primary/secondary). For 
the purpose of the present document, monotonically 
increasing is to be interpreted as increasing by 1 . This is 
used by the RKS to determine if Event Message are missing 
from a given network element. 


Unsigned integer 


4 bytes 


Event_time 


Event generation time and date. Millisecond granularity. This 
specifies the local time. i.e. after applying Time_Zone UTC 
offset and Daylight Savings Time adjustment to UTC time. 
Format: yyyymmddhhmmss.mmm 


ASCII character 
string 


1 8 bytes 


Status 


Status indicators 


See table 40 


4 bytes 
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Field Name 


Semantics 


Value Type 


Length 


Priority 


Indicates the importance to assign relative to other event 

messages. 

The processing of event message priority is defined as: 

-as long as there are higher priority messages within the 

system, lower priority messages should NOT be processed. 

-arrival of a higher priority message will not interrupt current 

lower priority message processing. Only after the completion 

of the message processing, the newly arrived higher 

message will be processed. 

For IPCablecom Release 1 .5, values for this field will be 

service provider assigned. 

255 = highest priority 

= lowest priority 

128 = default. 


Unsigned integer 


1 byte 


Attribute_Count 


Indicates the number of attributes that follow (or are 
appended to) this header in the current Event Message. 


Unsigned integer 


2 bytes 


Event_Object 


The Event_Object field allows for a grouping of services. 

= Accounting Event Message 

1 = PCES Event Message 

The CMS, CMTS and MGC network elements shall set the 

value of the Event_Object field to if the Event Message is 

sent to the RKS. 

The RKS shall discard EM messages when the 

Event_Object field is set to 1 . 

The CMS, CMTS and MGC network elements shall set the 

value of the Event_Object field to 1 if the Event Message is 

sent to the DF. 

The DF shall discard EM messages when the Event Object 

field is set to a value different than 1 . 


Unsigned integer 


1 byte 



9.1 .1 Billing Correlation ID (BCID) Field Structure 

Table 39 describes the Billing Correlation ID field (BCID). The RKS, or some other back office application, uses the 
BCID to correlate Event Messages that are generated for a single transaction. It is one of the fields in the Event 
Message Header attribute. The BCID is unique for each transaction in the network. All Event Messages with the same 
BCID should be sent to the same primary RKS except in failover circumstances in which case the Event Messages shall 
be sent to secondary RKS. 
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Table 39: BCID Field Description 



Field Name 


Semantics 


Value Type 


Length 


Timestamp 


High-order 32 bits of NTP time reference 


Unsigned integer 


4 bytes 


ElementJD 


Network wide unique identifier 

5 digits (statically configured element number unique within an 

IPCablecom domain in the range of 0-99,999) 


Right justified, space 
padded ASCII character 
string 


8 bytes 


Time_Zone 


Identifies daylight savings time and offset from universal time 
(UTC). 

Daylight Savings Time: 

= Standard Time 

1 = Daylight Savings 

The Daylight-Savings Time indicator shall be set to a value of 1 if 
the network element is in a region that implements DST and then 
only during the daylight-saving-time period (usually the summer 
months). Since there may be areas in which the daylight-saving- 
time offset indicates a time-change other than 1 hour, the 
receiving system (e.g. RKS) needs to correctly calculate local 
time based on knowledge of the area(s) in which the subscriber 
and the network element reside. 
UTC offset: ± HHMMSS 
The offset is reported from the network element 
(CMS/MGC/CMTS) point of view; not based on the subscriber 
point of view 

The UTC offset represents the time offset from universal time 
(formerly called Greenwich Mean Time, or GMT) when standard 
time is in effect and shall not change on transition into or out of 
daylight-saving-time. 

For example: The Time_Zone field of a network element in 
Boston in December is "0-050000". The same network element 
in Boston in July is "1-050000". 


ASCII character string 


1 byte 
7 bytes 


Event_Counter 


Monotonically increasing for each transaction. For the purpose of 
the present document, monotonically increasing Event_Counter 
is to be interpreted as a increasing number that is greater than 
the preceding number. 


Unsigned integer 


4 bytes 



The Related_Call_Billing_Correlation_ID attribute structure is shown in table 39. 
The Remote_Surveillance_Subject_BCID attribute Structure is shown in table 39. 

9.1 .2 Status Field Structure 

The Status field of the Event Message Header attribute is a 32-bit mask. Bit is the low-order bit; the field is treated as 
a 4 byte unsigned integer, table 40 presents Status field description. 
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Table 40: Status Field Description 



Bit 


Semantics 


Bit Count 


0-1 


Error Indicator: 

= No Error 

1 = Possible Error 

2 = Known Error 

3 = Reserved 

NOTE 1 : If the Error Indicator bit of the Status field is set to 2 (Known Error), the 

Error_Description attribute (EM attribute ID 31) shall be included in the 

Event Message corresponding to this header. 
NOTE 2: If the Error Indicator bit of the Status field is set to 1 (Possible Error), 

the Error_Description attribute (EM attribute ID 31) may be included in 

the Event Message corresponding to this header. 


2 


2 


Event Origin: 

= Trusted Element 

1 = Untrusted Element 


1 


3 


Event Message Proxied: 

= Not proxied, all data known by sending element 

1 = proxied, data sent by a trusted element on behalf of an untrusted element 


1 


4-31 


Reserved. 

The Status field bits 4 to 31 shall be set to 0. 


28 



9.2 



Call Termination Cause Attribute Structure 



Table 41 describes the data structure of the Call_Termination_Cause attribute. It is important to note that in some cases, 
the Call_Termination_Cause attribute may include a Call Completion Code that may indicate a successful call 
completion. 

Table 41 : Call Termination Cause Data Structure 



Field Name 


Semantics 


Value Type 


Length 


Source_Document 


Identifies the source Document of the Cause Codes: 

= Reserved 

1 = Telcordia Technologies Generic Requirements 

GR-1 1 00-CORE GR-1 1 00-CORE, Section 2.9, 
table 41 1 [6]. 

2 = Telcordia Technologies Generic Requirements GR-1 1 00- 

CORE, Section 2.9, table 235 [6]. A 
Source_Document value of 2 must only be used with 
the Service_lnstance Event Message. 

3 and above for future use. 


Unsigned 
integer 


2 bytes 


Cause_Code 


Cause Code Identifier. Meaning determined by 

Source_Document defined in previous field. The Cause_Code 

attribute is a 4 byte value. 

In the case where Source_Document = 1 , the IPCablecom 

Cause_Code is populated based only on the 

GR-1 1 00-CORE [6] (table 41 1) definition of character 2 (Cause 

Category) and characters 3-5 inclusive (Cause Indication), and 

encoding these 4 characters as an unsigned integer. Characters 

1 and 6 of table 41 1 are not relevant. 

For example, the encoding of a Cause_Code with Cause 

Category of ITU Standard (0) and a Cause Indication of "Normal 

Call Clearing" (016) is the unsigned integer value 0016. 

In the case where Source_Document = 2, the IPCablecom 

Cause_Code is populated based on the GR-1 1 00-CORE [6] - 

table 235 character 1 . 

For example, the encoding of a Cause_Code with a Call 

Completion Code "Not completed: Invalid authorization code" 

(3) is the unsigned integer value of 0003. 


Unsigned 
integer 


4 bytes 
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9.3 Trunk Group ID Attribute Structure 

Table 42 describes the Trunk Group ID Data Structure. 

Table 42: Trunk Group ID Data Structure 



Field Name 


Semantics 


Value Type 


Length 


Trunk_Type 


1 = when Non-SS7 (MF) direct trunk group is used 

2 = Not Used 

3 = when an SS7 signalling trunk is directly 
connected to IC/INC, SS7 direct trunk group number 

4 = when an SS7 signalling trunk is connected to IC 
via AT and SS7 from AT to EO 

5 = Not Used 

6 = when Non-SS7 trunk is used between the EO 
and AT and SS7 signalling trunk is used between 
AT and IC. (Terminating only) 

9 = Signaling type not specified 


Unsigned integer 
Value is the Trunk 
Group Signaling Type 
Indicator as defined in 
Telcordia GR-11 00- 
CORE [6], table 83. 


2 bytes 


Trunk_Group_Number 


ASCII Identifier. Values in the range 0000-9999. 


Right justified, space 
padded ASCII 
character string 


4 bytes 



9.4 QoS Descriptor Attribute Structure 

Table 43 describes the QoS Descriptor Data Structure. 

Table 43: QoS Descriptor Data Structure 



Field Name 


Semantics 


Value Type 


Length 


Status_Bitmask 


Bitmask describing structure 
contents. (See table 38) 


Bit map 


4 bytes 


Service_Class_Name 


Service profile name 


Right justified, space 
padded ASCII 
character string 


1 6 bytes 


QoS_Parameter_Array 


QoS Parameters. Contents 
determined by Status Bitmask. 


Unsigned integer array 


Variable length array of 32-bit 
unsigned integers 



Table 44 describes the QoS Status Bitmask field of the QoS Descriptor attribute. Bits 2-17 describe the contents of the 
QoS_Parameter_Array. Each of these bits indicates the presence (bit=l) or absence (bit=0) of the named QoS parameter 
in the array. The location of a particular QoS parameter in the array matches the order in which that parameter's bit is 
encountered in the bitmask, starting from the low-order bit. 

Each QoS parameter present in the QoS_Parameter_Array must occupy four bytes. The definition and encoding of the 
QoS parameters can be found in Appendix C of [i.3]. QoS parameters whose definition specifies less than four bytes 
must be right-justified (where the 4 bytes are to be treated as an unsigned integer) in the four bytes allocated for the 
array element. 
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Table 44: QoS Status Bitmask 



Start Bit 


Semantics 


Bit Count 





State Indication: 

= Illegal Value 

1 = Resource Reserved but not Activated 

2 = Illegal Value 

3 = Resource Reserved & Activated 


2 


2 


Service Flow Scheduling Type 




3 


Nominal Grant Interval 




4 


Tolerated Grant Jitter 




5 


Grants Per Interval 




6 


Unsolicited Grant Size 




7 


Traffic Priority 




8 


Maximum Sustained Rate 




9 


Maximum Traffic Burst 




10 


Minimum Reserved Traffic Rate 




11 


Minimum Packet Size 




12 


Maximum Concatenated Burst 




13 


Request/Transmission Policy 




14 


Nominal Polling Interval 




15 


Tolerated Poll Jitter 




16 


IP Type of Service Override 




17 


Maximum Downstream Latency 





9.5 



Redirected-From-lnfo Attribute Structure 



Table 45 describes the data structure of the Redirected-From-lnfo. 

Table 45: Data Structure of tlie Redirected-From-lnfo Attribute 



Field Name 


Semantics 


Value Type 


Length 


Last_Redi recti ng_Party 


E.164 [9] address of most recent 
redirecting party 


ASCII string 


20 bytes 


Original_Called_Party 


E.164 [9] address of the original called 
party 


ASCII string 


20 bytes 


Number_of_Redirections 


Number of times this call has been 
redirected 


Unsigned 
integer 


2 bytes 



9.6 



Electronic-Surveillance-lndication Attribute Structure 



Table 46 describes the data structure of the Electronic-Surveillance-Indication. The Electronic-Surveillance-Indication 
attribute appears in the SignaHng_Start EM or Surveillance_Stop EM. 

This attribute creates a "chain" of DFs as calls are redirected from one endpoint to another. In such scenarios, the DF 
associated with each CMS will be responsible for forwarding the call content and/or call data to the next DF in the 
chain. The last DF in the chain will then report the call content and/or call data to the appropriate LEA. If multiple 
surveillances are being performed, a DF in the middle of the chain may report the call content and/or call data to the 
appropriate LEA, as well as forward the call content and/or call data to the next DF in the chain. 

This attribute is included in a Signaling_Start EM to indicate to the DF where to forward call content and/or call data 
for a particular intercept. For example, in a CMSS environment, a CMS may perform surveillance at the request of 
another CMS due to a redirection by the subject. In such a scenario, the CMS would send call content and/or call data to 
its DF, and the DF would then forward the call data and call content to the DF responsible for delivering the call content 
and/or call data to the appropriate Law Enforcement Agency (LEA). 
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This attribute is included in a Surveillance_Stop EM when a CMS needs to indicate that surveillance will end, but the 
DF is not part of the surveillance chain as described above. This will occur in a CMSS environment when a CMS is 
redirected, and surveillance is requested as part of the redirection. In such a scenario, the CMS will normally request 
that the redirected-to CMS perform surveillance on behalf of the redirecting CMS, and a chain will be established 
between the redirected-to CMS and the redirecting CMS. However, the redirecting CMS may be in a jurisdiction in 
which surveillance cannot be performed. As a result, the CMS would send a Surveillance_Stop EM, and include the 
Electronic-Surveillance-Indication attribute, to ensure that the EM is forwarded to the DF of the redirecting CMS. 

Table 46: Data Structure of the Electronic-Surveillance-lndication Attribute 



Field Name 


Semantics 


Value Type 


Length 


DF_CDC_Address 


IP address of the electronic surveillance Delivery Function 
of the forwarding party for event messages 


IP Address 


4 bytes 


DF_CCC_Address 


IP address of the electronic surveillance Delivery Function 
of the forwarding party for call content packets 


IP Address 


4 bytes 


CDC_Port 


Port number to which to send a copy of event messages 


Unsigned 
integer 


2 bytes 


CCC_Port 


Port number to which to send a copy of call content packets 


Unsigned 
integer 


2 bytes 


Local_CCC_ID 


Call Content Identifier assigned by CMS or MGC 


Unsigned 
integer 


4 bytes 


Remote_CCC_ID 


Call Content Identifier assigned by CMS or MGC 


Unsigned 
integer 


4 bytes 


Remote_Surveillanc 
e Subject BCID 


BCID of the surveillance subject at the redirecting CMS 


Data Structure 
(See table 39) 


24 Bytes 



9.7 



Attributes For Conference Parties 



Table 47 describes the data structure of the attributes Communicating_Party, Joined_Part and Removed_Party. 
Table 47: Communicating_Party, Joined_Party and Removed_Party attributes 



Field Name 


Semantics 


Value Type 


Length 


PartyJD 


E.164 [9] formatted address specifying the number of the 
party. In the future other numbering plans will be 
addressed. 


Right justified, 
space padded 
ASCII 
character 
String. 


20 bytes 


CCC_ID_Valid 


When CCCJD is present this field is set to 1 ; otherwise it is 
set to 0. 


Unsigned 
integer 


2 bytes 


CCCJD 


The CCCJD associated with the call leg for the PartyJD. 
When the subject is one of the party in the conference, any 
of the active CCC IDs can be used. 
When CCCJD_Valid is not set (CCCJD not valid in the 
case of Call Data), this field is filled with the default binary 
value of all ones. 


Unsigned 
integer 


4 bytes 
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1 Transport independent event message attribute TLV 
format 

Every Event Message Attribute is defined by a Type Length Value (TLV) tuple. An attribute TLV tuple has the 
following format: 

Table 48: Event Message Attribute TLV-tuple format 



Field Name 


Semantics 


Field Length 


Attribute_Type 


IPCablecom Attribute Type 


1 byte (refer to table 37) 


Attribute_Length 


IPCablecom Attribute Length 


1 byte (refer to table 37) 
(See note). 


Attribute Value 


IPCablecom Attribute Value 


Attribute Length bytes 


NOTE: Value is Attribute Length + 2. 



1 1 IPCablecom event message file format 

The IPCablecom Event Message File Format has the following basic structure. 



11.1 File Bit / Byte Order 



Table 49 defines the Bit / Byte order for the Event Message file. For fields that span multiple bytes, the high-order bit of 
the field is the highest order bit of the lowest-numbered byte. Conversely, the low-order bit of a multi-byte field is the 
lowest-order bit of the highest-numbered byte. 

Table 49: Bit / Byte Order for the Event Message File 



Bit / Byte Order 


High-order Bit Low-order Bit 


Binary 




7 


6 


5 


4 


3 


2 


1 





High-order Byte 


Byte1 






































Low-order Byte 


Byte n 



















ETSI 



63 



ETSI TS 1 03 1 61 -6 V1 .1 .1 (201 1 -04) 



11.2 File Header 

The following header shall be written at the start of a file formatted using the IPCablecom Event Message File Format: 
Table 50: File Header for IPCablecom Event Message File Format 



Field Name 


Semantics 


Length 


Type 


Format_Version 


Identifies the version of this file format. The value must 
be 1 to comply this version of the EM specification. 


4 bytes 


Unsigned int 


EM Count 


Number of EMs in File 


8 bytes 


Unsigned int 


File Creation Timestamp 


YYYYMMDDHHMMSS.MMM 


1 8 bytes 


ASCII 


File_Sequence_Number 


Monotonically increasing for each new file. For the 
purpose of the present document, monotonically 
increasing is to be interpreted as increasing by 1 . 


8 bytes 


Unsigned int 


ElementJD 


Network wide unique identifier 

5 digits (statically configured element number unique 
within an IPCablecom domain in the range of 0-99,999) 


8 bytes 


Right justified, 
space padded ASCII 
character string 


Time_Zone 


Identifies daylight savings time and offset from universal 
time (UTC). 

Daylight Savings Time: 

= Standard Time 

1 = Daylight Savings 

The Daylight-Savings Time indicator shall be set to a 
value of 1 if the network element is in a region that 
implements DST and then only during the daylight- 
saving-time period (usually the summer months. Since 
there may be areas in which the daylight-saving-time 
offset indicates a time-change other than 1 hour, the 
receiving system (e.g. RKS) needs to correctly calculate 
local time based on knowledge of the area(s) in which 
the subscriber and the network element reside. 
UTC offset: ±HHMMSS 

The UTC offset represents the time offset from 
universal time (formerly called Greenwich Mean Time, 
or GMT) when standard time is in effect and shall not 
change on transition into or out of daylight-saving-time. 
For example: the Time_Zone field of a network element 
in Boston in December is "0-050000". The same 
network element in Boston in July is "1-050000". 


1 byte 
7 bytes 


ASCII character 
string 


File_Completion_Timesta 
mp 


YYYYMMDDHHMMSS.MMM 


1 8 bytes 


ASCII 



There is no checksum included in the file header. It is assumed that the transport mechanism is responsible for delivery 
of damage-free files. For example, both of the IP transport protocols, UDP and TCP, contain a checksum to protect 
against damaged messages. 



1 1 .3 File Naming Convention 



Files created using the IPCablecom Event Message File Format shall use the following naming convention: "PKT- 
EM_yyyymmddhhmmss_pri_type_elementid_seq.bin." 
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1 1 .3.1 Filename Components 

Table 51 describes each of the components of the filename: 



Table 51 : Filename Components 



Component 


Semantics 


Type 


Length 


FileJD 


Identifies this file as containing IPCablecom Event 
Messages 


Literal string 'PKT-EM' 


6 characters 


Timestamp 


Time at which file was opened by the network element 


yyyymmddhhmmss 


1 4 characters 


Priority 


Priority of this file 

When processing multiple files with differing priorities, 

files of higher priority must be processed before the 

lower priority files. 

File priority should be established by the application 

creating the file. 


Integer in the range 1-4 

4 is the highest 

1 is the lowest 

A default value of 3 is 

recommended. 


1 character 


Record_Type 


This flag identifies the record type contained in the file. 
Primary records indicate new, while secondary records 
indicate previously transmitted 


Binary 

If the file contains 
primary usage data this 
will be a (zero) if it 
contains a 1 (one) the file 
contains secondary data. 


1 characters 


ElementJD 


Network wide unique identifier 

5 digits (statically configured element number unique 

within an IPCablecom domain in the range of 0-99,999) 

with leading zeros for padding. 

e.g. element id = 99 

PKT-EM yyyymmddhhmmss pri type 00099 seq.bin 


Right justified, zero 
padded ASCII character 
string 


5 characters 


Sequence_Number 


Monotonically increasing sequence number for each 
new file. For the purpose of the present document, 
monotonically increasing is to be interpreted as 
increasing by 1. 


A fixed length character 

string that allows only the 

characters 0-9, with an 

interger range of 000001- 

999999. 

Left most positions are 

always padded with zero. 


6 characters 



Each element of the filename components is separated by an underscore "_" character. The segment delimiter will also 
enable segments to be distinguishable simply by a parsing process. 



1 1 .4 Configuration Items 



The following items shall be configurable by the IPCablecom network element creating the file: 

Table 52: Required Configuration Items 



Name 


Semantics 


Type 


Length 


Maximum File Length 


Maximum size of file, in bytes, to which flat file can grow 
before being closed for transport. 


Unsigned integer 


4 octets 


Maximum Open Time 


Maximum amount of time, in seconds, before file must 
be closed for transport. 


Unsigned integer 


4 octets 



The IPCablecom Network Element that created the file shall close any currently open flat file at the first occurrence of 
either of the following events: 



• The file size exceeds the Max File Length. 

• The file open duration exceeds the Maximum Open Time. 
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1 1 .5 File EM Structure Header 

When an EM is written out to a file, each event message shall be identified by a structure header. 
The following identifies the File-based EM Packet Structure. 

Table 53: File-based EM Packet Structure 



Field Name 


Semantics 


Description 


ID 


Indicates an ElVI structure 


2 byte, value of OxAA 55. 
The value OxAA 55 is chosen to enable 
synchronization of the EM boundary if there 
are any errors within an event message. 


Length 


Indicate the length of the entire EM structure 


2 bytes, length of all attributes + 4 


attributes 


Refer to table 48. Event Message Attribute TLV-tuple 
format. 


Event Message attributes 



1 2 Transport Protocol 



This clause specifies the possible transport protocols used between the IPCablecom network elements that generate 
Event Messages (CMS, CMTS, MGC) and the Record Keeping Server (RKS). These network elements shall support 
RADIUS Accounting (RFC 2866 [5]) with IPCablecom extensions as defined in the present document. The optional 
transport protocol is FTP as defined in the present document. 

The following are the IPCablecom transport requirements: 

• The transport protocol may support confidentiality of Event Messages. 

• End-to-end security across multiple administrative domains is not required. 

• RADIUS protocol parameters. 

• Retry interval and Retry count. 

• For each RKS that may receive Event Messages, its IP address and UDP port. 

• The IP address of each RADIUS server that it may communicate with. 



12.1 RADIUS Accounting Protocol 



The RADIUS Accounting protocol is a client/server protocol that consists of two message types: Accounting-Request 
and Accounting-Response. IPCablecom network elements that generate Event Messages are RADIUS clients that send 
Accounting-Request messages to the RKS. The RKS is a RADIUS server that sends Accounting-Response messages 
back to the IPCablecom network elements indicating that it has successfully received and stored the Event Message. 

The Event Messages are formatted as RADIUS Accounting-Request and Accounting-Response packets as specified in 
RFC 2866 [5]. Although IPCablecom 1.5 specifies RADIUS as the transport protocol, alternate transport protocols may 
be supported in future IPCablecom releases. 

12.1.1 Reliability 

The RADIUS messages are transported over UDP, which does not guarantee reliable delivery of messages, hence the 
request/response nature of the protocol (see RFC 2865 [4] for the technical justification of choosing UDP over TCP for 
the transport of Authentication, Authorization, and Accounting messages). 
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When an RKS receives and successfully records all IPCablecom Event Messages in a RADIUS Accounting-Request 
message, it shall send an Accounting-Response message to the client. If the IPCablecom network element does not 
receive an Accounting-Reponse within the configured retry interval, it shall re-send the same Accounting Request either 
to the same RKS or the alternate RKS (retries may alternate between primary and secondary RKS in a vendor- specific 
way). The IPCablecom network element shall continue resending the Accounting-Request until it receives an 
acknowledgement from an RKS or the maximum number of retries is reached. The RADIUS server shall not transmit 
any Accounting-Response reply if it fails to successfully record the Event Message. 

Once a Network Element succeeds in sending event messages to the secondary RKS server, a failover to the secondary 
RKS should occur. This is a non-revertive failover, meaning that the secondary RKS becomes active, and is the new 
primary RKS. For calls in progress, all subsequent event messages should be sent to the now active secondary RKS. For 
all new calls, the CMS should instruct the CMTS and MGC to use the new active RKS as the primary (i.e. the previous 
secondary RKS becomes the new primary for subsequent calls). 



12.1.2 RADIUS Client Reliability 

All Network Elements shall store Event Messages until they have received an Acknowledgement (Ack) from an RKS 
that the data was correctly received and stored, or until the maximum number of retries has been reached. Only when an 
Ack is received or the maximum retries reached are the NEs allowed to delete these Event Messages. If the maximum 
retries is reached, the NEs should write the Event Messages to an error file before deleting these Event Messages. 

In order to guarantee the reliable transfer of the data, the Radius Client should implement a user configurable Radius 
message Ack interval and the number of times the client needs to retransmit the event or message. The time interval 
should be configurable (suggested: 10 msec to 10 sec), the number of retries should be configurable (suggested: to 9). 
The number of retries should be attempted on both the primary RKS and secondary RKS. After exhausting the number 
of retries, the event message should be written to an error file and the event message can then be deleted from the 
network element. 

NOTE 1: The Radius Client MIB (RFC 2620 [i.l9]) does not contain these parameters. 

NOTE 2: This requirement implies that the RKSes use highly reliable storage media and are also highly available. 

12.1.3 Authentication and Confidentiality 

Refer to the IPCablecom security specification [2] for details concerning the use of IPSec to provide both authentication 
and confidentiality of the RADIUS messages, and the details of the correct usage of the RADIUS shared secret. 

12.1.4 Standard RADIUS Attributes 

Each RADIUS message starts with the standard RADIUS header shown in table 54. 

Table 54: RADIUS Message Header 



Field Name 


Semantics 


Field Length 


Code 


Accounting-Request = 4 
Accounting-Response = 5 


1 byte 


Identifier 


Used to match accounting-request and accounting-response messages. 


1 byte 


Length 


Total length of RADIUS message 
min value = 20 
max value = 4 096 


2 bytes 


Authenticator 


Computed as per RADIUS Specification [5] 


1 6 bytes 



Two standard RADIUS attributes shall follow the RADIUS Message Header: N AS -IP- Address and Acct_Status_Type. 
These two fields are included to improve interoperability with existing RADIUS server implementations since they are 
mandatory attributes in a RADIUS Accounting-Request packet. 

The NAS -IP- Address indicates the originator of the Accounting-Request message and shall contain the IP address of 
the originating IPCablecom network element. 
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The Acct-Status-Type attribute typically indicates whether the Accounting-Request marks the beginning of the user 
service (Start) or the end (Stop). Since an IPCablecom Accounting-Request message may contain multiple Event 
Message Packets, it could contain Event Messages which mark both the beginning and end of the user service. For this 
reason, an Acct-Status-Type value of Interim-Update is used to represent IPCablecom Event Messages. 

Table 55: Mandatory RADIUS Attributes 



Name 


Type 


Length 


Value 


NAS-IP-Address 


4 


6 


IP address of originating IPCablecom network element 


Acct-Status-Type 


40 


6 


lnterim-Update=3 



Table 56: RADIUS Acct_Status_Type 



Type 


Length 


Value 


40 


6 bytes 


Interim-Update = 3 



IPCablecom attributes are defined in clause 9 of the present document. IPCablecom attributes are encoded in the 
RADIUS Vendor Specific Attributes (VSA) structure as described in this clause. Additional IPCablecom or vendor- 
specific attributes can be added to existing Event Messages by adding additional RADIUS VSAs to the message. 

The Vendor-Specific attribute includes a field to identify the vendor, and the Internet Assigned Numbers Authority 
(IAN A) has assigned IPCablecom an SMI Network Management Private Enterprise Number of 4 491 for the encoding 
of these attributes. The RKS server should ignore Event Messages where the IPCablecom "Event Message type" is 
unidentified. The RKS server should also ignore IPCablecom event attributes where the event attribute type is 
unidentified. 

Table 57: Radius VSA Structure for IPCablecom Attributes 



Field Name 


Semantics 


Field Length 


Type 


Vendor Specific = 26 


1 byte 


Length 


Total Attribute Length 

NOTE: Value is Vendor Length + 8. 


1 byte 


Vendor ID 


CableLabs = 4 491 


4 bytes 


Vendor Attribute Type 


IPCablecom Attribute Type 


1 byte (refer to table 37) 


Vendor Attribute Length 


IPCablecom Attribute Length 


1 byte (refer to table 37) 

NOTE: Value is Vendor Length +2. 


Vendor Attribute Value 


IPCablecom Attribute Value 


Vendor Length bytes 



12.1.5 IPCablecom Extensions 

1 2.1 .5.1 IPCablecom RADIUS Accounting-Request Packet Syntax 

<<RADIUS Accounting-Request> ::== 

<RADIUS message Header> 
<RADIUS NAS-IP-Address Attribute> 
<RADIUS Acct-Status-Type Attribute> 
<IPCablecom EM List> 

<IPCablecom EM List> ::== 

<IPCablecom EM> | 

<IPCablecom EM List> <IPCablecom EM> 

<IPCablecom EM> ::== 

<RADIUS VSA for IPCablecom EM Header Attribute> 
<IPCablecom EM Attribute List> 

<IPCablecom EM Attribute List> ::== 

<RADIUS VSA for IPCablecom EM Attribute> | 

<IPCablecom EM Attribute List> 
<RADIUS VSA for IPCablecom EM Attribute> 
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The potential of a high Event Message volume raised the concern that the RADIUS mechanism for ensuring reliability 
via request/response may consume too much bandwidth or be too computationally intensive. This led to the requirement 
that it be possible to transmit multiple IPCablecom Event Messages in a single RADIUS message. The use of this 'batch 
mode' is left to the discretion of the IPCablecom network element and will likely depend on the latency requirements of 
the particular event type. The number of Event Messages encapsulated in a single RADIUS message is still subject to 
the maximum RADIUS message length restriction of 4 096 bytes. 

The Event Message Header shall be the first attribute within a given Event Message. If multiple Event Messages are 
sent in a single RADIUS Accounting-Request, the Event Message Header attribute indicates the start of a new Event 
Message. The order of the Event Message attributes which follow the Event Message Header is arbitrary. 

IPCablecom extends RADIUS Accounting, by introducing new attributes and new values for existing attributes. Since 
the RADIUS protocol is extendable in this manner, it is expected that existing RADIUS server implementations will 
require minimal modifications to support the batch collection of IPCablecom Event Messages. 



12.1.5.2 



Concatenation of Attributes 



The Vendor Specific Attribute (VSA) limits the size of the attribute value to 247 bytes (see table 57). However there 
may be instances where the attribute value cannot fit into a single VSA, for example, the SDP attributes used in 
electronic surveillance. In cases where the value of an attribute is greater than 247 bytes, the network element shall 
create multiple attributes of the same type in the RADIUS message. The attributes shall be adjacent to one another 
within the message and shall be sequential such that the order of the original attribute value is maintained. The recipient 
in this case shall concatenate the multiple attributes into a single attribute value. Note that regardless of multiple 
attributes being present in an event message, the message is subject to the maximum RADIUS message length 
restriction of 4 096 bytes. Attributes that are concatenated in this manner shall be from the list presented in table 58. 

Table 58: Concatenated Attributes 



EM Attribute Name 


ElVI Attribute ID 


SDP_Upstream 


39 


SDP Downstream 


40 


RTCP Data 


93 


Local XR Block 


94 


Remote XR Block 


95 



1 2.2 File Transport Protocol (FTP) 



The File Transfer Protocol (FTP) [i.l2] may be used by an IPCablecom network element to transport Event Messages to 
the RKS. The RKS shall have FTP Server support. If this transport protocol is used, the RKS hosts an FTP server to 
accept files transferred by the IPCablecom network element. The IPCablecom network element acts as the FTP client, 
pushing the files to the RKS for processing. 

If FTP is used as a transport protocol, then the file shall be formatted using the IPCablecom Event Message File Format. 

12.2.1 Required FTP Server Capabilities 

The FTP Server at the RKS shall have at minimum the following capabilities: 

• Minimum implementation as described in Internet Protocol Standards - STD9 [i.l2] Section 5.1. 

• PASV Mode (passive mode) command. 

• Data Type I, Image (binary). 

• Authentication support (PASS command). 

• File Transfer logging. 
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The FTP client should listen for the 226 response to the STOR (close data connection) to indicate the file was 
successfully transferred and excepted by the RKS before marking the file as transferred. The NE should attempt to 
resend the file during the next scheduled FTP session if a response other than 226 is received. 
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Annex A (normative): 
PCES Support 



This clause details the IPCablecom Event Messages and their associated attributes that shall be generated to support 
IPCablecom Electronic Surveillance as defined in [8]. The following requirements apply to all PCES Event Messages: 

• The appropriate network element (CMS,CMTS, MGC) shall send the PCES Event Message to the DF in real- 
time as defined in [8]. 

• The PCES Event Message sent to the DF shall not affect the monotonically increasing Sequence-Number that 
appears in the Event Message header sent to the RKS. 

• All PCES Event Messages shall have the Event_Object field in the EM_Header attribute set to one. 

• PCES Event Messages shall not be sent to the RKS. 

• The following requirements apply to all PCES components responsible for sending or receiving Event 

Messages: 

Intercept Access Points (e.g. CMS, CMTS, MGC) and Delivery Function (DF) shall support the Radius 
Protocol over UDP as defined in clause 12 except for 12.1.1 and 12.1.2. 

If an lAP does not receive an Accounting-Response message within the configured retry interval, it shall 
continue resending the same Accounting-Request until it receives an acknowledgement from the DF or 
the maximum number of retries is reached. The lAP may drop the request after the maximum retries is 
reached. 

When a DF receives PCES Event Message in a Radius Accounting-Request message from an lAP, it 
shall send an Accounting-Response message to the lAP. 
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A.1 Servicejnstance 

If the service is under surveillance as defined in [8], the Servicejnstance Event Message shall be generated with all the 
standard required parameters and with the additional required electronic surveillance parameters. 

Table A.I : Servicejnstance Event Message for PCES 



Attribute Name 


Required or 
Optional 


Comment 


EM_Header] (see table 38) 


R 


The EM Header attribute shall be present as the first attribute 
of the EM. 


Service_Name 


R 


The Service_Name attribute shall be present. 

Class Service Name: 

CalLBIock 

Call_Forward 

Call_Waiting 

Repeat_Call 

Return_Call 

Three Way Call 


Call_Termination_Cause 





The Call_Termination_Cause attribute shall be present if 
Service Name is Call Block. 


Redirected_From_Party_Number 





2 = The Redirected_From_Party_Number attribute shall be 
present if Service Name is Call Forward. 


Redirected_To_Party_Number 





The Redirected_To_Party_Number attribute shall be present 
if Service Name is Call Forward. 


CarrierJdentification_Code 





The CarrierJdentification_Code attribute shall be present if 
Service_Name is Call_Forward and transit carrier is used to 
transport the redirected call. 


Related_Call_Billing_CorrelationJD 





The Related_Call_Billing_CorrelationJD attribute shall be 
present if Service_Name is Call_Forward, Call_Waiting or 
Three Way Call. 


Charge_Number 





The Charge_Number attribute shall be present if 
Service_Name is Call_Forward, Call_Waiting, Repeat_Call, 
Return_Call or Three_Way_Call. 


First_Call_Calling_Party_Number 





The First_Call_Calling_Party_Number attribute shall be 
present if Service Name is Call Waiting. 


Second_Call_Calling_Party_Number 





The Second_Call_Calling_Party_Number attribute shall be 
present if Service_Name is Call_Waiting. The 
Called_Party_Number shall also be present for Return_Call 
when it's not included in the Signaling Start message . 


Called_Party_Number 





The Called_Party_Number attribute shall be present if 
Service Name is Call Waiting. 


Routing_Number 





The Routing_Number attribute shall be present if 
Service Name is Repeat Call or Return Call. 


Calling_Party_Number 





The Calling_Party_Number attribute shall be present if 
Service_Name is Repeat_Call or Return_Call. 



A.2 Signaling_Start 



If the service is under surveillance as defined in [8], this Event Message shall be generated with all the standard 
required parameters and with the additional required electronic surveillance parameters. 

The MGC shall generate, timestamp, and send this event to the DF for a terminating call under surveillance to a PSTN 
Gateway. 

• The MGC shall timestamp this message coincident with sending the SS7 I AM message or transmitting the 
dialed digits on an MF-trunk. 
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For an originating call from an MTA or from a PSTN Gateway, if the MGC receives notification via signalling 
from the terminating CMS that the call is to be intercepted but the terminating device is unable to perform the 
interception, the MGC shall timestamp and send an additional Signaling_Start event message to the Electronic 
Surveillance Delivery Function prior to delivering a response to the originating MTA or PSTN Gateway. This 
Signaling_Start event message shall contain the Electronic_Surveillance_Indication attribute, and the value of 
the Directionjndicator attribute shall be integer 2 (2=Terminating). 

The CMS shall generate, timestamp, and send this event to the DF if the originating call from an MTA is under 
surveillance. 

The CMS shall timestamp and send this event message DF after all translation of the dialed digits is complete, 
whether the translation is successful or not. This includes unroutable digits reported to the CMS (i.e. partially 
dialed digits). 

The CMS shall generate, timestamp, and send this event to the DF. for a terminating call to an MTA under 
surveillance, or for a terminating call under surveillance to an MTA. 

The CMS shall timestamp and send this event message to the Electronic Surveillance Delivery Function prior 
to invoking any termination features. 

Table A.2: Signaling_Start Event Message for PCES 



Attribute Name 


Required or 
Optional 


Comment 


EM_Header (see table 38) 


R 


The EM Header attribute shall be present as the first attribute of 
the EM. 


Direction Indicator 


R 


None 


l\/ITA_Endpoint_Name 





If the originating CMS generates this message, this attribute shall 

contain the endpoint name of the originating MTA. 

If the terminating CMS generates this message, this attribute shall 

contain the endpoint name of the terminating MTA. 

If the originating MGC generates this message, this attribute may 

contain the endpoint ID of the originating MG. 

If the terminating MGC generates this message, this attribute may 

contain the endpoint ID of the terminating MG. 


Calling_Party_Number 





The Calling_Party_Number attribute shall be included whenever it 
is available in SS7 or CMSS signalling. For example, in the off-net 
to on-net scenario, this attribute may not be present when the 
Originating MGC and Terminating CMS do not have the Calling 
Party Number attribute available from SS7 signalling. 


Called Party Number 


R 


terminating address (E.164 [9] format) 


Routing Number 


R 


Routable number 


Location_Routing_Number 





The Location_Routing_Number attribute shall be included if a LNP 
lookup returns a LRN. 


Carrier_ldentification_Code 





This attribute shall be included in MGC generated messages in 
which the call is being routed to an inter-exchange carrier and the 
information is available. 


Trunk_Group_ID 





This attribute shall be included when the MGC generates this 
message. 


Userjnput 





Shall be present for a call origination event, and shall contain the 
original dialed digits received from MTA or from PSTN Gateway. 


Translationjnput 





Shall be present if an external database was consulted for 
translation, and the input for that external translation was different 
than the value of User-Input. 


Red i rected_From_l nf o 





Shall be included for a call termination if information is available 
about previous redirections. 


Electronic_Surveillance_lndication 





The Electronic_Surveillance_lndication attribute shall be present 
in events sent to DF for terminating calls that have been 
redirected by a surveillance subject. 
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A.3 Signaling_Stop 



If the service is under surveillance as defined in [8], this Event Message shall be generated with all the standard 
required parameters and with the additional required electronic surveillance parameters. 

This Event Message indicates the time at which signalling terminates. It is intended to capture the point at which the NE 
processes the final signalling message for the call. A Signaling_Stop message shall not be generated unless a 
Signaling_Start message with the same BCID has been generated for the call. A Signaling_Stop message shall be 
generated if a Signaling_Start message with the same BCID has been generated for the call (in exception cases, this 
may be the result of a proprietary time-out or clean-up process). 

Originating CMS 

In the single-zone scenario, the originating CMS shall timestamp this EM message immediately upon transmission of 
the NCS-signalling DLCX message. 

In the intra-domain or inter-domain scenarios, the originating CMS shall timestamp this message upon transmission of 
the last signalling event in the following list: 

• transmission of the NCS-signalling DLCX message; or 

• transmission of the CMS S- signalling BYE message or CANCEL message; 

• Terminating CMS. 

In the single-zone scenario, the terminating CMS shall timestamp this EM message immediately upon transmission of 
the NCS-signalling DLCX message. 

In the intra-domain or inter-domain scenarios, the terminating CMS shall timestamp this message upon transmission of 
the last signalling event in the following list: 

• transmission of the NCS-signalling DLCX message; or 

• transmission of the CMS S- signalling BYE message or the transmission of the CMS S- signalling 
acknowledgment response message to a CANCEL request. 

Originating MGC (off-net to on-net) 

The originating MGC shall timestamp this EM message immediately upon the last signalling event in the following list: 

• transmission/receipt of an RLC to/from the Signaling Gateway that communicates with the SS7 network; 

• transmission of the MGC-issued TGCP DLCX message; 

• receipt of an MG-issued TGCP DLCX; or 

• transmission of the CMS S- signalling BYE message or CANCEL message. 

Terminating MGC (on-net to off-net) 

The terminating MGC shall timestamp this EM message immediately upon transmission of the TGCP-signalling DLCX 
message. 
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Table A.3: Signaling_Stop Event Message 



Attribute Name 


Required or 
Optional 


Comment 


EM_Header (see table 38) 


R 


The EM Header attribute shall be present as the first attribute 
of the EM. 


Related_Call_Billing_Correlation_ID 





If the originating CMS or MGC generates this message, the 
Related_Call_Billing_Correlation_ID attribute shall contain the 
BCID of the terminating CMS or MGC when terminating CMS 
or MGC is known. If the terminating CMS or MGC is not known, 
this attribute may be omitted. 

If the terminating CMS or MGC generates this message, the 
Related_Call_Billing_Correlation_ID attribute shall contain the 
BCID of the originating CMS or MGC if known. If the BCID of 
the originating CMS or MGC is not known this attribute may be 
omitted. 


FEID 





If the originating CMS or MGC generates this message, the 
FEID attribute shall contain the FEID of the terminating CMS or 
MGC when terminating CMS or MGC is known. If the 
terminating CMS or MGC is not known, this attribute may be 
omitted 

If the terminating CMS or MGC generates this message, the 
FEID attribute shall contain the FEID of the originating CMS or 
MGC. 


Call Termination Cause 


R 


The Call Termination Cause code shall be present. 



A.4 Call_Answer 

If the service is under surveillance as defined in [8], then this Event Message shall be generated with all the standard 
required parameters and with the additional required electronic surveillance parameters. 

The CMS or MGC shall send this Event Message to the DF. 



A.5 Call_Disconnect 

If the service is under surveillance as defined in [8], then this Event Message shall be generated with all the standard 
required parameters. 

The CMS or MGC shall send this Event Message to the DF; 



A.6 QoS Reserve 



If the service is under surveillance as defined in [8], then this Event Message shall be generated with all the parameters 
described in table A.4. 

The CMTS shall generate this message if: 

1) the CMTS generates a QoS_Reserve Event Message as defined in clause 8.17; and 

2) the COPS Electronic-Surveillance-Parameters object was included in the Gate-Set message to the CMTS, and 
the flag indicates dup-event. 
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Table A.4: QoS_Reserve Event Message for PCES 



Attribute Name 


Required or 
Optional 


Comment 


EM_Header (see table 38) 


R 


The EM_Header attribute shall be present as the first 
attribute of the EM. 


QoS Descriptor 


R 


None 


MTA UDP Portnum 


R 


None 


SF ID 


R 


None 


Flow Direction 


R 


None 


CCC ID 


R 


None 





A.7 QoS Release 



If the service is under surveillance as defined in [8], then this Event Message shall be generated with all the parameters 
described in table A. 5. 

The CMTS shall generate this message if: 

1) the CMTS generates a QoS_Release event message as defined in clause 45; and 

2) the Electronic-Surveillance-Parameters object was included in the Gate-Set message to the CMTS, and the flag 
indicates dup-event. 

Table A.5: QoS_Release Event Message for PCES 



Attribute Name 


Required or 
Optional 


Comment 


EM_Header (see table 38) 


R 


The EM_Header attribute shall be present as the first 
attribute of the EM. 


SF ID 


R 


None 


Flow Direction 


R 


None 


CCC ID 


R 


None 



A.8 QoS Commit 



If the service is under surveillance as defined in [8], then this Event Message shall be generated with all the parameters 
described in table A. 6. 

The CMTS shall generate this message if: 

1) the CMTS generates a QoS Commit Event Message as defined in clause 8.16; and 

2) the COPS Electronic-Surveillance-Parameters object was included in the Gate-Set message to the CMTS, and 
the flag indicates dup-event. 
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Table A.6: QoS_Commit Event Message for PCES 



Attribute Name 


Required or 
Optional 


Comment 


EM_Header (see table 38) 


R 


The EM_Header attribute shall be present as 
first attribute of the EM. 


the 


QoS Descriptor 


R 


None 


MTA UDP Portnum 


R 


None 


SF ID 


R 


None 


Flow Direction 


R 


None 


CCC ID 


R 


None 





A.9 Media_Report 



This Event Message is used by the CMS and MGC to report media stream status and session description information 
(SDP) to the DF. The CMS and MGC shall send this message: 

1) When it opens a new media channel and receives confirmation containing SDP. Typically the sending of this 
message would be triggered by the positive acknowledgement of an NCS or TGCP modify connection in 
which reservations were requested. The "Channel_State" attribute is set to "Open" in this case. 

NOTE 1: This is the message that the DF uses to trigger sending a CCOpen message to the CF (refer to [8]). 

2) When it closes a media channel. Typically the sending of this message would be triggered by the positive 
acknowledgement of an NCS or TGCP delete connection. The "Channel_State" attribute is set to "Close" in 
this case. 

NOTE 2: This is the message that the DF uses to trigger sending a CCOpen message to the CF (refer to [8]). 

3) When it receives new SDP for an open media channel. Typically the sending of this message would be 
triggered by the positive acknowledgement of an NCS or TGCP modify connection in which SDP was 
received. The "Channel_State" attribute is set to "Change" in this case. 

NOTE 3: This is the message that the DF uses to trigger sending a CCClose message to the CF (refer to [8]). 

The CMS or MGC shall timestamp this message on receipt of response from an endpoint that triggered the sending of 
the message (e.g. response from a modify or delete connection). 

Table A.7: Media_Report Event Message for PCES 



Attribute Name 


Required 
or Optional 


Comments 


EM_Header (see table 38) 


R 


The EM Header attribute shall be present as the first attribute of 
the EM 


CCCJD 





The CCCJD attribute shall be present for call content surveillance. 

CMS and MGC provide CCCJD. 

The CCCJD attribute shall not be present for call data 

surveillance. 


SDP_Upstream 





The SDP_Upstream attribute shall be included if SDP is received 
from the surveillance subject's associate. 


SDP_Downstream 





The SDP_Downstream attribute shall be included if SDP is 
received from the surveillance subject 


Channel_State 


R 


The Channel_State attribute shall be included and set to "Open" if 
a new channel has been opened, "Change" if SDP is being 
provided for an opened channel, "Close" if the media channel has 
been closed. 


Flow_Direction 


R 


The Flow_Direction attribute shall be included and indicates 
direction of flow: Upstream or Downstream. 
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A.10 Signaljnstance 



If the service is under surveillance as defined in [8], the Signaljnstance message shall be generated and timestamped 
when any of the following events occurs, unless the information reported in the Signaljnstance message would be 
redundant with the information reported by other Event Messages (e.g. Signaling_Start): 



1) 



2) 



The CMS receives a positive acknowledgement in response to a NotificationRequest command that requested 
immediate generation of a signal contained in table A. 8 toward the surveillance subject. 

The CMS receives a Notify command that indicates the surveillance subject's initiation of a signal contained in 
table A. 9. For DTMF tones, the CMS shall not generate the Signaljnstance message until it has received all 
of the digits provided by the surveillance subject. 

Table A.8: Signals Sent Toward Intercept Subject 



NCS Code 


Description (Name) 


0-9,*,#AB,C,D 


DTMF tones 


bz 


Busy tone 


cf 


Confirmation tone 


ci(ti,nu,na) 


Caller Id 


dl 


Dial tone 


mwi 


Message waiting indicator 


ot 


Off-hook warning tone 


r0,r1,r2,r3,r4,r5,r6,r7 


Distinctive ringing 


rg 


Ringing 


ro 


Reorder tone 


rs 


Ringsplash 


rt 


Ring back tone 


si 


Stutter dial tone 


vmwi 


Visual message waiting indicator 


Wt1,wt2,wt3,wt4 


Call waiting tone 



Table A.9: Signals Received From Intercept Subject 



NCS Code 


Description (Name) 


0-9,*,#AB,C,D 


DTMF tones 


ft 


Fax tone 


hf 


Flash hook 


mt 


Modem tones 


TDD 


Telecomm Devices for the Deaf (TDD) tones 



When the generation of the Signaljnstance message is due to Condition 1 in the above requirement, the Signal_Type 
attribute in table A. 10 shall be set to a value of "1". The value of "1" identifies the other attributes in table A. 10 that are 
relevant to this condition, namely the Alerting_Signal, Subject_Audible_Signal, Terminal_Display_Info, and 
Misc_Signaling_Information attributes. These attributes shall be present in the Signal_Instance message generated per 
Condition 1 if the condition presented in the Comment column of the corresponding table row is met. 

When the generation of the Signaljnstance message is due to Condition 2 in the above requirement, the Signal_Type 
attribute in table A. 10 shall be set to a value of "2". The value of "2" identifies the other attributes in table A. 10 that are 
relevant to this condition, namely the Switch_Hook_Flash, Digits_Dialed and Misc_Signaling Jnformation attributes. 
These attributes shall be present in the Signaljnstance message generated per Condition 2 if the condition presented in 
the Comment column of the corresponding table row is met. 
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Table A.10: Signaljnstance Event Message for PCES 



Attribute Name 


Required or 
Optional 


Comment 


Event Message Header (table 38) 


R 


The EM_Header shall be present as the first attribute of the EM. 


Signal_Type 


R 


1 = Network_Signal 

2 = Subject Signal 


Signaled_To_Number 





shall be present if Signal_Type =1 
shall not be present if Signal Type =2 


Signaled_From_Number 





shall not be present if Signal_Type =1 
shall be present if Signal_Type =2 


Alerting_Signal 





shall be present if Signal_Type =1 and the following signals are 

detected: 

r0,r1,r2,r3,r4,r5,r6,r7 

rg 

rs 

wt1 ,wt2,wt3,wt4 


Subject_Audible_Signal 





shall be present if Signal_Type =1 and the following signals are 

detected: 

bz 

cf 

dl 

mwi 

ot 

ro 

rt 

si 


Terminal_Display_lnfo 





shall be present if Signal_Type =1 and the following signals are 

detected: 

ci(ti,nu,na) 

vmwi 


Switch_Hook_Flash 





shall be present if Signal_Type =2 and the following signals are 

detected: 

hf 


Dialed_Digits 





shall be present if Signal_Type =2 and the following signals are 

detected: 

0-9,*,#AB,C,D 


Misc_Signaling_lnformation 





shall be present if the following signals are detected: 

0-9,*,#AB,C,D (for Signal Type 1) 

ft 

mt 

TDD 
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A.1 1 Terminal_Display_lnfo Attribute Structure 

Table A. 11 describes the data structure of the Terminal_Display_Info attribute. 

Table A.11 : Terminal_Display_lnfo Attribute Data Structure 



Field Name 


Semantics 


Value Type 


Length 


Terminal_Display_ 
Status Bitmask 


Bitmask describing structure contents (see table 
A. 12) 


Bit map 


1 byte 


General_Display 


Used to report undefined display-related signals 

sent toward the surveillance subject. 

Field is populated with text that describes the 

signal. 


Right justified, 
space padded 
ASCII character 
string 


80 bytes 


Calling_Number 


Calling number information for Caller Id signal 
(ci/nu) that is displayed on the surveillance 
subject's terminal. 
Field is populated as follows: 

- If signal includes a calling number, value is 
number. 

- If signal indicates privacy ("P") for calling 
number, value is "private". 

- If signal indicates unavailability ("0") for calling 

number, value is "unavailable". 

- If signal does not include anything (number, "P" 
or "0") for calling number, Calling_Number field 

is not included in Terminal_Display_lnfo attribute. 


Right justified, 
space padded 
ASCII character 
string 


40 bytes 


Calling_Name 


Calling name information for Caller Id signal 
(ci/na) that is displayed on the surveillance 
subject's terminal. 
Field is populated as follows: 

- If signal includes a calling name, value is name. 

- If signal indicates privacy ("P") for calling name, 
value is "private". 

- If signal indicates unavailability ("0") for calling 

name, value is "unavailable". 

- If signal does not include anything (number, "P" 
or "0") for calling name, Calling_Name field is not 

included in Terminal Display Info attribute. 


Right justified, 
space padded 
ASCII character 
string 


40 bytes 


IVIessage Waiting 
Notif 


Information for Visual message waiting indicator 

signal (vmwi). 

Field is populated as follows: 

- If indicator is turned on by signal, value is 
"VMWI ON". 

- If indicator is turned off by signal, value is 
"VMWI OFF". 


Right justified, 
space padded 
ASCII character 
string 


40 bytes 



Table A. 12 describes the Terminal_Display_Status_Bitmask field of the Terminal_Display_Info attribute. Bits 0-3 
describe the contents of the Terniinal_Display_Info attribute fields. Each of these bits indicates the presence (bit=l) or 
absence (bit=0) of the named Terminal_Display_Info attribute field. 

Table A.12: Terminal_Display_Status_Bitmask 



Bit 


Semantics 


Bit Count 





General Display 




1 


Calling_Number 




2 


Calling_Name 




3 


IVIessage Waiting Notif 




4 


Reserved 




5 


Reserved 




6 


Reserved 




7 


Reserved 
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A. 1 2 Conference_Party_Change 

This Event Message is used by a CMS to report the change in the participants of a conference call. The CMS shall 
generate this Event Message for a conference call that was initiated by the user under surveillance, when: 

• The subject adds a third, or additional parties, to an existing to call to form a conference call. 

• A party in a subject-initiated conference call is placed on hold. 

• A party in a subject-initiated conference call is retrieved from hold. 

When the subject adds a party, all the parties to the call (including the newly added party) are reported as 
communicating parties, and the newly added party is also reported as a joined party. When a party is placed on hold, all 
the remaining parties are reported as communicating parties, and the party on hold is reported as a removed party. When 
a party is retrieved from hold, all the parties (including the retrieved party) are reported as communicating parties, and 
the party retrieved from hold is also reported as a joined party. Multiple parties may be added, placed on hold, or 
retrieved from hold at the same time. All parties would be reported within the same Conference_Party_Change 
message. Note that the Signaling_Stop message is used to indicate when a party in a subject-initiated conference call is 
dropped, released, or otherwise disconnected from the conference call. 

EXAMPLE 1: A (the subject) calls B, and A creates a conference that includes A, B and C. This Event Message 
is generated with A,B, and C listed as communicating parties, and C listed as the joined party. 

EXAMPLE 2: A (the subject), B and C are in a conference created by A. When C goes on hold, this Event 

Message is generated with A and B listed as communicating parties and C listed as removed party. 

EXAMPLE 3: A (the subject), B and C are in a conference created by A but C has gone on hold. When C joins 
the conference again, this Event Message is generated with A,B and C listed as communicated 
parties and C listed as joined party. 

Table A.13: Conference_Party_Change Event Message 



Attribute Name 


Required or 
Optional 


Comment 


EM_Header (see table 38) 


R 


The EM_Header attribute shall be present as the first attribute of the EM. 
Within the EM_Header, the BCID shall be one of the BCIDs associated 
with a call leg participating in the conference call. 


Communicating_Party 





This attribute shall be included when known, to identify all communicating 
party identity(ies), when the conference is established by the intercept 
subject's service. This attribute may appear multiple times, one for each 
communicating party in the call. This attribute may appear independently 
or in combination with other attributes. 


Joined_Party 





This attribute shall be included when known, to identify a communicating 
party identity(ies) when added to the conference established by the 
intercept subject's service. This attribute may appear multiple times, one 
for each added party. This attribute may appear independently or in 
combination with other attributes. 


Removed_Party 





This attribute shall be included when known, to identify a previously 
communicating party identity(ies), when removed (e.g. placed on hold) 
from the conference established by the intercept subject's service. This 
attribute may appear multiple times, one for each removed party. This 
attribute may appear independently or in combination with other 
attributes. 



A.13 Surveillance_Stop 



Surveillance_Stop indicates the end of call content and/or call data. Generally, this will mean the end of a call. 
However, this can also indicate that call content and/or call data can no longer be intercepted (e.g. a call has been 
forwarded to another service provider's network and cannot be intercepted). 
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The CMS shall timestamp this EM immediately upon: 

• The end of a call. A call has ended when a Signaling_Stop is sent for the call leg under surveillance and the 
call has not been redirected. The Surveillance_Stop_Type would be set to 1 "End of surveillance". 

• The CMS determining that surveillance cannot be started, or can no longer be performed. For example: 

A call is redirected to a jurisdiction in which surveillance cannot be requested, a CMS may continue to 
perform call data surveillance, but not call content surveillance. In such a case, the CMS would send a 
Surveillance_Stop indicating that call content will end. The Surveillance_Stop_Type would be set to 2 
"End of CCC only". 

A call is redirected to a jurisdiction in which surveillance cannot be requested, and CMS will no longer 
be part of the call path. In such a case, the call has not ended, but the CMS would still send a 
Surveillance_Stop indicating that both call content and call data surveillance will end. The 
Surveillance_Stop_Type would be set to 1 "End of surveillance". 

Generally, a DF that receives a Surveillance_Stop will be part of a "chain" of DFs (for more information refer to 
clause 9.6) that are responsible for forwarding call data and call content down the chain. A chain is established when the 
CMS has already sent a Signaling_Start with the Electronic_Surveillance_Indication attribute. In this case, the 
Electronic_Surveillance_Indication attribute shall not be included in the Surveillance_Stop. However, under certain 
scenarios a CMS may send a Surveillance_Stop to its DF even though the DF is not part of the surveillance chain being 
stopped. In this case, the CMS shall include the Electronic_Surveillance_Indication attribute in the Surveillance_Stop 
EM to identify the remote surveillance session that is to be stopped. For example, consider the case where a CMS 
receives a SIP Redirect with a request to perform surveillance, and the redirect is to a jurisdiction in which surveillance 
cannot be performed. In such a scenario, the CMS would send a Surveillance_Stop to its DF, and the DF would then 
forward the Surveillance_Stop EM to the appropriate DF based on the information in the 

Electronic_Surveillance_Indication attribute. Note that in this scenario the BCID in the EM_Header would not be 
bound to the remote surveillance session being stopped; therefore the Electronic_Surveillance_Indication attribute is 
required in order to ensure the Surveillance_Stop EM is forwarded to the appropriate DF. 

Table A.I 4: Surveillance_Stop Event Message for PCES 



Attribute Name 


Required 
or Optional 


Comments 


EM_Header (see table 38) 


R 


The EM Header attribute shall be present as the first attribute of the 
EM. 


Surveillance_Stop_Type 


R 


1 = End of surveillance (CDC and, if present, CCC) 

2 = End of CCC only (CDC will continue) 


Surveillance_Stop_Destination 





In certain CMSS scenarios, a CMS may continue to perform 
surveillance on a local subject, but can no longer perform 
surveillance (call content and/or call data) on behalf of another CMS. 
This parameter indicates to the DF which subject (local and/or 
remote) the Surveillance_Stop EM applies to. 

1 = Surveillance_Stop applies to local surveillance only 

2 = Surveillance_Stop applies to both local and remote surveillance 

3 = Surveillance_Stop applies only to remote surveillance 


Electronic_Surveillance_lndication 





This structure shall be included when the local DF is not part of the 
DF chain (i.e. the CMS has not established a DF chain by not 
including the Electronic_Surveillance_lndication attribute in a 
Signaling_Start EM). 

This structure shall not be included when the local DF is part of the 
DF chain (i.e. the CMS has established a DF chain by including the 
Electronic Surveillance Indication attribute in a Signaling Start 
EM). 
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A. 14 Redirection 



The Redirect Event Message allows the DF to generate the Redirection ESP Message for those cases where a 
Service_Instance Event Message is not reported from the CMS to the DF. The Redirection message shall be sent to the 
DF if a call involving a surveillance subject is redirected and: 

• the CMS is aware of the redirection; 

• no Service_Instance is generated for the redirection. 

The CMS is aware of the redirection as a result of the following triggers: 

• The subject or associate is on the same CMS that is responsible for the surveillance and that party initiates a 
redirection via a call transfer. 

• The subject or associate is on the same CMS that is responsible for the surveillance and call forwarding is 
activated for that party. 

• The CMS responsible for the surveillance receives a CMSS 302 REDIRECT indicating that the call has been 
forwarded at a remote CMS. 

• The CMS responsible for the surveillance receives a CMSS REFER indicating that the call has been 
transferred at a remote CMS. 

Table A.15: Redirection Event Message for PCES 



Attribute Name 


Required 
or Optional 


Comments 


EM_Header (see table 38) 


R 


The EM Header attribute shall be present as the first attribute of 
the EM. 


Related_Call_Billing_Correlati 
on ID (See table 39) 





Included when the redirected call will be identified by a different 
Call ID in future CDC messages. 


Redirected_From_Party_Num 
ber 





Identifies the redirected-from party. 

This field shall be included when the subject is performing the 

redirection. 


Redirected_To_Party_ 
Number 


R 


Identifies the redirected-to party (forwarded-to or transferred-to 
party). 


Carrier_ldentification_Code 





Included when a transit carrier is used to transport the redirected 
call and the carrier information is available to the CMS. 
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